Encrypted Password for Oracle JDBC

[Richard Joyce]

Hi,

I'm trying to set up my application to use an encrypted password to connect to Oracle 9i using JDBC.

At present I'm storing the password as plain text in a .properties file. the Database username and password are stored here and used to create a Connection object.

However I now need to encrypt the password, most likely using a cipher so that the password isn't stored or tranmitted in plain text.

Does anyone out there know whats required in the Java code and also how to configure Oracle NetManager - Oracle Advanced Security to do this?

I believe it is a case of adding additional connection properties in the Java code and configuring Oracle, but I'm not haveing much luck with it...

thanks in advance

rejoyce1976

[Shailesh Chandra]

You can keep encrypted id/password in .properties file, decrypt them in java before conecting to database.

There are a lot of API available on internet which will do your task of encryption/decryption.

Thanks,
Shailesh

[Richard Joyce]

Hi,

thanks for your reply, but thats not what I'm looking to do. I want to store the password in an encrypted form in a properties file, but I don't want to decrypt it using Java, I want to send it to Oracle in encrypted form. Our requirement is that passwords aren't stored OR tranmitted in plaintext.

I believe that oracle can be configured to know that the password is encrypted and decrypt accordingly. There are also java.util.Properties that need to be set when connectiong

eg:

Properties props = new Properties();
props .put("oracle.net.encryption_client","REQUIRED");
props .put("oracle.net.encryption_types_client", "DES40C");
props .put("oracle.net.crypto_checksum_types_client","MD5");
con = DriverManager.getConnection("jdbcracle:thin:@10.30.173.75:1521:sid", props);

just wondered if anyone out there has ever managed to acheive this?

I know there's configuration required on the Oracle side and also the correct properties need to be set in the java code...

thanks

R.

[Shailesh Chandra]

Richard, I am sorry I do not have much idea of same. But one thing which I know is that every encryption is done using an algorithm, how oracle will come to know about same, unless encryption is done using some oracle utility which shares same algorithm.

Thanks,
Shailesh

[Ulf Dittmer]

I may be misunderstanding something, but in this scenario, how is storing the encrypted password in a file better than storing the cleartext password? If it can be used to log into the DB, then there's really no difference between the two approaches, is there?

[Richard Joyce]

Hi,

thanks for you reply,

My company have a requirement that passwords are not stored in the clear in properties files. the reason being I suppose that if the password is stored in plaintext someone could hit the property file directly, get the password and then connect to the database with it.

For a regular user connecting through an Oracle client or SQL Developer they would need to have the plaintext password in order to connect.

its based on the requirements of

International Standards Organization Guidance

ISO 17799 � 9.5.4 requires password management systems to:
� enforce the use of individual passwords
� allow users to select and change their own passwords if appropriate
� enforce a choice of quality passwords
� force regular changes of passwords
� maintain a record of previous user passwords to prevent re-use
� not display passwords when they are being entered
� store password files separately from application system data
� store passwords in encrypted form using a one way encryption algorithm
� alter default vendor passwords following installation of software

So if I can store the password encrypted using a one way algorithm then hacker/user couldn't decrypt it and then access the database.

I have feeling there is a way of configuring this in Oracle advanced Security, but just can't quite get it to work.

thanks

Rich

[Ulf Dittmer]

This is talking about something different, namely about storing passwords in a database. You shouldn't store passwords in cleartext, so what you do is to hash them (or digest them - so-called one-way encryption) and store them that way. Since hashing is not reversible, nobody can retrieve the plaintext password, not even the DBA. So upon login, whatever password you enter will also be hashed, and only if it matches the stored password hash, will you be able to log in.

If your security requirements are actually this formalized, then you should not store passwords in files on user machines at all. The application should require the user to enter the password when it starts up. And that should be the user password, not a DB password that is the same for many people (because that has very little authentication value).

[Richard Joyce]

Hi,

Our requirements are based on the items from the ISO recommendations. We are not storing any passwords in the database. How this requirement affects me is we cannot store our database password in a .properties file in plaintext in our Java application. It has to be encrypted in someway. I don't think it can be encrypted using assymetric encryption as we'll either need to decrypt it before using it or else it'll be passed to oracle encrypted and Oracle will know to decrypt it.

I have been unable thus far to configure Oracle Advanced Security to know to expect an encrypted password. So I am going to spend a bit of time working on using a Symmetric encryption algorithm to encrypt the password and store it in the properties file as encrypted. Then in the java application decrypt it and pass it up to Oracle on authentication. Do you have any idea if the traffic between JDBC type 4 Drive and Oracle is encrypted or passed in plaintext?

If I can store my password as encrypted and Type 4 Driver takes care of passing it to Oracle using its own encryption then I'll fulfill my requirement...

thanks

R.

[Ulf Dittmer]

Yes, I understand the requirement. My post was intended to highlight a situation where the part applies that you bolded in your post; and it doesn't apply in your situation.

What I'm trying to get across, though, is that storing passwords in a file is not a good idea, encrypted or unencrypted. If an encrypted password password can be passed to Oracle, and that's sufficient to access the DB, then it's not even marginally better than using an unencrypted password if either would be stored in file (and is thus equally likely to be accessed by an attacker).

So unless the encrypted password is stored in a file and is decrypted by the application before being passed to Oracle -with the decryption key being something that the user enters, and which is not stored anywhere- then you might as well not use encryption at all, because there's no security gain.

As to encrypting DB traffic in transit, most drivers can use SSL for that. Googling for "oracle jdbc ssl" shows many relevant hits.

[Richard Joyce]

Hi,

Our application is running in the Spring Framework and we set up a Apache commons dbcp BasicDataSource for connecting to the database. The database password has to be specified in the config file. Its not running in a container which has supports connection pools so the password has to be stored in a file. I know it might not be ideal, but without any other solution its what I have to do. the requirement is that passwords are stored in plaintext, so i'm just trying to fulfill that.

If you have any suggestions for how to do it I'd be interested to hear.

thanks

Richard

[Ulf Dittmer]

Tricky. If the properties file on the client machine is seen as an attack target, so must be the application executable itself. That means the attacker can get hold of the class files, decompile them, and circumvent all (or most) security measures it implements.

Short of the user entering the password I see no secure solution (and making the user remember a password increases the chances of it being written down, decreasing security).

Sorry of not being more helpful, but this requirement doesn't seem to make much sense in terms of increased security.

[Richard Joyce]

Originally posted by Ulf Dittmer:
Tricky. If the properties file on the client machine is seen as an attack target, so must be the application executable itself. That means the attacker can get hold of the class files, decompile them, and circumvent all (or most) security measures it implements.

Short of the user entering the password I see no secure solution (and making the user remember a password increases the chances of it being written down, decreasing security).

Sorry of not being more helpful, but this requirement doesn't seem to make much sense in terms of increased security.

No don't get me wrong, the properties file isn't on the clients machine. this is an application running on a Sun SOLARIS Server.

Also there is no user really, as the server runs and intereacts with a web application whcih is running on another server. The application would interact with the web application, but not directly with a user.

I've decided i'm going to use a simple cipher to encrypt the DB password, Its not going to make the application un crackable by an means, but it is going to fulfill my requirement that passwords aren't stored in plain text