Any way in which i can Import the tables without revealing password?

[Kunal Lakhani]

I have created an application with swing and hibernate.
I have to ship the application to a different place. So, i will be dispatching the disc containing Application(in .exe format), and oracle Express edition software.
They will install the Oracle software. And then they will run the script (table structures)/ or import the file (.sql) and then will use the application. I have used "Hibernate" as the username and "ItsJavaKamaal" as the password, and have included in my app.(configuration file). The app has been converted to exe (after creating jar). If exe can be converted to jar, one can see the config.xml, and will get the username password. I don't want to reveal the password, neither i want the client to see the tables directly through oracle.

What should i do?
Is it possible?

[Gene Hilpert]

If they are installing oracle express, that means that they have the adminstration user and password and with those they can get into any schema.

[Kunal Lakhani]

But, my tables will be created with different username,password
Can i create different user (and set password) and grant dba role to it via java code. I don't want to reveal the username password in any way

[Paul Clapham]

To follow up on what Gene Hilpert said, why don't you just let them import the tables using the administrator's ID and password? I don't understand the point of using some other secret password for that.

[Gene Hilpert]

That means other general users will not be able to see them but the the adminstration user does backups, create users, grant roles, exports and imports so it needs to be able to get at to all data. Think of it as a super user.

The only way you might be able to do what you want is to have the user enter the adminsration id and password that was used to install oracle and change it to something only your program will know. But there is high risk in doing this.

[Kunal Lakhani]

I am not getting this.
So, let us take an example. Suppose administrator username is "Chris" and password is "Management". My application uses is the username as "hibernate" and password is "java". So, do i need to reveal it to the client? Actually, i don't want client to be able to see the datas and tables with username as "hibernate"

[Paul Clapham]

I am not getting it either. The user can sign on as the administrator and do whatever they like with your tables, so I don't see what the purpose of your special user ID is.

[Gene Hilpert]

Another option is to determine what data is most important and encrypt those columns. You will take a hit on speed to encrypt and decrypt but it would protect your data more. A lot of work for little payback if you ask me.

[Kunal Lakhani]

Paul, if the user signs in with his credentials, i.e "Chris", i don't think he can see details (i.e tables and datas of user "hibernate"). Correct me if i am wrong. Since the administrator can only create users and grant roles, can i do this (i.e creation of user and granting role ) via Java code??? If yes, i will tell the client what to keep as administrator username and password (and i will hardcode it in my code for able to create user and granting roles)

[Gene Hilpert]

Oracle is like a database of databases, The main database is called an "instance". inside the instance are users or schemas. the users have tables and columns like payroll and addresses. But the Instance also has tables that hold things like user_names, table_names and tables that hold where to put the log files and things like that. The admin user run the space allocations, monitoring the database and create users.

[Gene Hilpert]

You can grant roles that are normaly adminstrator roles to other users, so i user can create other users.
Its been awhile since I played with XE but It least at one time that was an admin id user.

[Kunal Lakhani]

As far as i know, the client is not aware of database or programming language... I am 100% sure. So i don't think he will bother to find out the my username credentials, unless and until i give him. And i really don't want to . That's why i asked in my previous post :

Since the administrator can only create users and grant roles, can i do this (i.e creation of user and granting role ) via Java code??? If yes, i will tell the client what to keep as administrator username and password (and i will hardcode it in my code for able to create user and granting roles)

[Paul Clapham]

Kunal Lakhani wrote:As far as i know, the client is not aware of database or programming language... I am 100% sure.

Well, so far you haven't said why you want to do this (even though you have been asked a couple of times). But if it's for some kind of security, then what you said there is no security at all.

[Gene Hilpert]

When you installed it what did it ask you?
If it asked you what user to create first that would most likely be the admin id too. in that case what I said is moot.

[Kunal Lakhani]

I have mentioned the reason. I simply don't want the client to look into the table and datas. This is the only reason, and motive. There is no other reason. Hope i am able to explain my requirement clearly.

[Kunal Lakhani]

It doesn't asks to create any user. So, i can simply connect "scott/tiger" or "system/tiger"(assuming that "tiger is set as a password while installing")
So can i do this (i.e creation of user and granting role ) via Java code??? If yes, in this case, i will not have to reveal my username and password (i.e "hibernate/java")

I am very much confused. I think i am not able to explain it clearly.

If i am talking nonsense, Sorry

[Martin Vashko]

If you allow your users to install and run the software themselves on a computer they fully control, then any protection you can get is based just on the ignorance of your users. Anyone mildly skilled with Oracle will probably be able to see your data in minutes.

If your installation procedure includes running SQL scripts from using sqlplus (or something similar), the password will very probably be presented more or less in cleartext in some installation scripts or bat files. However, you might then (at the end of the installation procedure) change the password to something more secure using your Java program. The password need not be stored in a config file, you might compile it into a .class file, or you might store it encrypted. You could even create a random password, encrypt it and store it into a file on the computer. But again, all this will not give you protection from more skilled, or just curious, users.

Did you try to search the Oracle XE documentation for possible installation scenarios? There might be some tips which would help you design the installation procedure.

[Kunal Lakhani]

However, you might then (at the end of the installation procedure) change the password to something more secure using your Java program

If i can change the password using java program, can't i create user and grant it roles through Java code???

[Kunal Lakhani]

What i did , is , created the user, granted the dba role, and then created tables. I did all these through java code.

Just a sample

package org.nit.Service;

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.PreparedStatement;

public class CreateDBUser {

	/**
	 * @param args
	 */
	public static void main(String[] args) {
		try {
			Class.forName("oracle.jdbc.driver.OracleDriver");
			Connection con = DriverManager.getConnection("jdbc:oracle:thin:@localhost:1521:XE", "System", "tiger");
			PreparedStatement ps = con.prepareStatement("CREATE USER sampleUser IDENTIFIED BY sampleUser");
			ps.execute();
			System.out.println("User Created");
			PreparedStatement ps1 = con.prepareStatement("grant dba to sampleUser");
			ps1.execute();
			System.out.println("Role granted");
		} catch (Exception e) {
			e.printStackTrace();
		}


	}
}

package org.nit.Service;

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.PreparedStatement;

public class CreateTables {
	
	public static void main(String[] args) {
		try {
			Class.forName("oracle.jdbc.driver.OracleDriver");
			Connection con = DriverManager.getConnection("jdbc:oracle:thin:@localhost:1521:XE", "sampleUser", "sampleUser");
			PreparedStatement ps2 = con.prepareStatement("create table studentpersonal (enrollmentNo number(10) CONSTRAINT studentper_eno_pk PRIMARY KEY,fullname varchar2(30),sex  varchar2(10),DateOfBirth  date,fathersName  varchar2(30),fathersQual  varchar2(20),mothersName  varchar2(30),mothersQual  varchar2(20),address varchar2(100),city varchar2(20),state varchar2(20),contactNo number(14),guardiansName  varchar2(30),guardiansRelation varchar2(30),guardiansAddress varchar2(100),guardiansContact  varchar2(14),status varchar2(10))");
			ps2.executeUpdate();
			System.out.println("Table created");
		} catch (Exception e) {
			e.printStackTrace();
		}


	}


}

This works perfect. But still, need your opinions.

Thanks

[Martin Vashko]

I can still log in as system/tiger, can't I? And once I log in as an admin, I can grant myself all the permissions over your tables.

Perhaps you could lock the system account, or change its password (and that of sys as well). But you'll prevent the user from managing his database. I'm not sure it really is what you (or them) want.

[Martin Vashko]

One more thought: the users will be entering their data to your application, right?

Why do you want to prevent the users from seeing their own data in the database?

[Kunal Lakhani]

Thanks Martin for your reply.

Actually the client has a data entry operator. And he will be handling those datas. So, i got orders from client to do something through which that operator can't see the data directly through oracle.

[Martin Vashko]

Then the database should be definitely hosted on a different computer, which the operator cannot physically access.

And perhaps there should be an application server, which would connect to the database on its own, so that the operator cannot establish direct connection to the DB.

Or, if the user just inserts the data, but doesn't ever need to view them again, you might grant him just INSERT privilege over the tables; even if he connects to the database directly, he won't see anything. Or it could be set up so that he can see only the data which belong to his responsibility (and which he can see in the application anyway). In other words, built the security model into the database, then the user will be able to see only the data he is authorized for, regardless of whether he connects through your application or directly via an SQL client.

[Kunal Lakhani]

thanks Martin for your reply