How to avoid storing credentials to connect to Ora

Question

Is it possible to setup a JDBC connection to Oracle without providing username/password information in a configuration file (or in any other standard readable location)?

Typically applications have a configuration file that contains setup parameters to connect to a database. Some DBAs have problems with the fact that usernames and passwords are in clear text in config files.

I don't think this is possible with Oracle and JDBC, but I need some confirmation...

A possible compromise is to encrypt the password in the config file and decrypt it before setting up the connection. Of course, the decryption key should not be in the same config file. This will only solve accidental opening of the config file by unauthorized users.

Answer 1

All J2EE containers (JBOSS, Tomcat, BEA) have connection pools. They will open a number of connections, keep them alive and will give them to you in 1/100^th the time it takes to create one from scratch.

Additionally, they also have cool features, in JBOSS for example, all the connection info is stored in an external file. If you change the connection info i.e., you switch from a test to a production DB, your application will dynamically be fed connections from the new pool

The good news is that you don't need to run a full J2EE container just to use connection pooling. The external resource allows the password to be stored in either plaintext, or pseudo-encrypted.

For a guide on using Tomcat's builtin connection pooling see the apache commons-dbcp:

• http://vigilbose.blogspot.com/2009/03/apache-commons-dbcp-and-tomcat-jdbc.html

Answer 2

Have wondered this in the past.

The solution is certainly one that includes having proper network security at the server and network level to really reduce the number of people who can get access to the system, and having the database credentials only give access to a database account with the bare minimum of permissions required for the application to run.

Encryption of properties files might be enough of a deterrent in terms of "can't be bothered to find the key or passphrase" to get an attacker to go onto their next compromised server. I wouldn't rely on "my neighbour is less secure so steal from him please" security however!

Answer 3

You definitely don't want to be able to connect to the database without credentials because that makes the database vulnerable.

This is a general problem, how do I store credentials needed to access external systems? WebLogic has a credential mapper to solve this problem, in which credentials (encrypted) are stored in embedded LDAP. Many Oracle products use a credential store facility that stores credentials in Oracle wallet.

In the question, you provided the answer. Store the password encrypted and decrypt when you need it. Obviously you have to use symmetric encryption algorithm such as 3DES so you can decrypt it. Make sure the symmetric key is not something that can be guessed.

The trick is where you keep the symmetric key needed for en/de-cryption. You can put it in a file that is secured through the OS or you can keep it in the code, but then you need to keep the code secure. You can also generate the key if you use a technique that will produce the same key and the algorithm is reasonably secure.

If you can keep the code secure you can obviously keep the password in the code as well. However, you want the flexibility of being able to change the credentials without changing the code.

You can add more layers to this solution as well. You can encrypt the configuration file (with a different key) as well as the password inside it making the hacker discover 2 keys. There are other even more secure methods using PKI, but they get hard to set up.

Answer 4

To my knowledge jdbc connection usernames/passwords need to be stored as plain text. One way to limit the possible risks of this is to restrict the rights of the user so that only the given applications database can be used and only from a predefined host. IMO, this would limit the attacker very much: he could only use the un/pw from the same host where the original application resides and only to attack the original application's database.

Answer 5

You can store the credentials anywhere, including as hardwired strings in the program or as entries in the Windows registry. It's up to you to retrieve them if you use something nonstandard, though; I'm not aware of any pre-rolled solutions that aren't plaintext.