views:

427

answers:

5

I have a plain Java application which is supposed to connect to the database. I don't want to store database connection url and username/password in a properties file or hardcode it in application. What is a common way to solve this problem? How a Java application can connect to database without revealing username/password?

+3  A: 

If you aren't willing to store it, you have to prompt for it. You could encrypt the password, but then you have to have a key to decrypt it and you are stuck in the same problem.

Travis Jensen
Right - that may be an good option. There is another option - storing username/password in a separate location and allowing my Java application getting those u/p combination without revealing them to the user who is running it through some kind of proxy library. or JNDI?
Alex
+3  A: 

I'm a .NET dev, but I've run into the exact same situation.

Last year I was working at a company that had to be PCI compliant to store credit card data, so security was a big deal. The URL/login data has to exist somewhere. The most common method I've seen for securing it is with encryption. I don't know about Java in particular, but .NET has several encryption namespaces in the core Framework. We used these to encrypt the database logins.

You still have a potential security vulnerability, which are the encryption keys used to encrypt/decrypt the data. We used the PCI "compensating controls" method here. Access to the keys is restricted to "key management" role. We also tracked access of the key itself so that there was a record of all user-initiated and system-initiated access. No one user had access to these logs, so there could be no covering of tracks by a single user. These overlapping security methods essentially create a situation where nothing less than a coordiated conspiracy between multiple administrators is required to put the data in jeopardy.

Dave Swersky
A: 

The best way would be to store the information as a configured data source in the JNDI context of your application server. You can then use the facilities of the application server to configure data sources at deployment time. All the application has to do is look up the appropriate JNDI name at runtime and use that. This is a common pattern for Java web applications.

Peter Kelley
Right. But my application is not running inside Application server. It's a standalone Java application. yes, I can connect to JNDI from it and can get datasource reference from it, but it is not a recommended practice. JNDI datasource should be used only by apps running INSIDE application server.
Alex
All you really do here is push the problem off, though. Now you have to worry about how the app server handles that data. Again, either the server has clear access to it or you have to provide a key to the app server.
Travis Jensen
+1  A: 

One of the common solutions to this problem for server based applications is to store the username and password in a file that has user permissions set in such a way that only the executing user of the application/service can read its contents.

For example, you run your application as user foo-service and it inherits all of the access privileges of the foo-service user. The file containing the username and password is only readable by that user. You read the value from the file and connect to the database as normal.

Possible problems with this approach:

  • The superuser of this machine may be able to get the password to the database.
  • An attacker who has penetrated your application security can get access to the database credentials.

The above problems are normally mitigated by tuning the access privileges for the application to the database and the network. Nearly any other solution you come up will get you into a chicken-and-egg problem because you are basically trying to hide something from itself.

Elijah
A: 

Use web services to separate your application from the server doing the database access. Sign your web application and then only allow a properly signed application to call the web services server.

Martlark