The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Protecting the db password in a servlet client setup

We have a web application (Apache + Tomcat) that connects to a postgresql database running on the same server.

We've secured the database client authentication by following the steps outlined here: http://www.postgresql.org/docs/7.4/interactive/client-authentication.html (i.e. only one db user id has access, a password is needed as part of authetication, no client connections are accepted from foreign/non-localhost servers, etc.).

But there remains one vulnerability: the servlet itself (in the scheme of things, the servlet is the only db client allowed; end users won't know there's a db involved at all).

Since all the JDBC connection examples we've seen use a properties file or ResourceBundle, we're stuck (unless somewhere here can suggest an alternative) leaving the db password in plaintext on the server somewhere.

The properties files is protected in the sense that it's owned by root and readble by root only (chmod 400) and it's located on the server in a place where no web user would have access (it falls outside the Directory location specified in httpd.conf).

An alternative, of course, would be to hardcode the password in the servlet source code, but that creates other problems around maintenance, and it's not really secure since decompiling the class files will reveal the password.

Anything else we could try instead?
DP
Wednesday, July 06, 2005
 
 
You could try obfuscating it.  ROT-13 or similar, which is essentially what ALL encryption methods, including DES and AES, work out to in this situation.
Chris in Edmonton Send private email
Wednesday, July 06, 2005
 
 
Can you limit the database to only allow connections from localhost?

Then you could put the password anywhere...
KC Send private email
Wednesday, July 06, 2005
 
 
Chris -- yes, we were thinking of doing something like that (e.g. use a message digest like md5 or sha-1 to encrypt the password, copy and paste the result into the properties file, and have the java code that reads the properties file decrypt it with the same digest).

It makes maintenance a little more difficult, which is ok, but I'm not sure how much security we're actually getting for that -- decompile the class file and you know which digest we used b/c java's MessageDigest class requires you to specify the digest as a string like this:  java.security.MessageDigest d = java.security.MessageDigest.getInstance("SHA-1");

Once you know the digest and have the properties file, you can decrypt the password.

KC, yes, we've blocked all db logins such that you have to be on the localhost before you're even allowed to to try to login to the db -- sorry if I didn;t make that clearer in my original message.
DP
Wednesday, July 06, 2005
 
 
>Anything else we could try instead?

nope.

seriously, thats all I've ever encountered- save setting up a biometric scanner to restrict root access from the terminal. I will certainly keep an eye on this thread for something new!

At this point I'd be more concerned about going through my code and identifying possible entry points for SQL injection attacks (non parameterized queries, un-validated user input, etc) as well as making sure all non-essential services are off and the firewall is properly set (all that network stuff)...

good luck!
...But What Do I Know
Wednesday, July 06, 2005
 
 
Stored procedures.  We're using a system with two accounts - one admin that can get to everything, and one that can only modify data with stored procedures.  Only put the limited account password on that box.  That's a start, at least.  There's more to it than that, of course.
Aaron F Stanton Send private email
Wednesday, July 06, 2005
 
 
Depends on the application setup. You could enter the db password on a HTML page and with that enable the application. Once the servlet gets reloaded, you need to do that again.

On Unix you could store the password so provided in a file which you open, keep open and delete (from a common jar file which is not under the webapp classloader). Unless the JVM is restarted, you can read the password again and again without anyone else being able to open that file.

Seriously, storing the password in a file is not as bad as it  may sound. If someone can circumvent your file permissions, he is most likely also able to alter your servlet code, generating HTML like "<a href="dbpassword goes here"></a>" somewhere on your site.
icing Send private email
Thursday, July 07, 2005
 
 
Change the password reglarly and maybe the encryption algorithm. This does not prevent a break in but limits the time system is vunerable.
John
Thursday, July 07, 2005
 
 
The safest way is for the server to ask the sysadmin for the passphrase. Directly through the terminal, like open-ssl.

A static method in one of your preloaded classes/servlets might work: haven't tried it. If that fails, a small Apache module which asks for the passphrase would do the trick (save the password with server_rec->ap_set_module_config() and access it again in the Java class).

Of course everyone I know finds entering the SSL passphrase every time tedious and disables it. Which replicates your issue (ie, no one working apache ssl has a solution for your problem - the key is left out in the open and we are told to make the key only root-readable).
slava Send private email
Thursday, July 07, 2005
 
 
This may be over-engineered, but you can use krb5 authentication in place of storing the password in the clear.

http://www.postgresql.org/docs/7.4/interactive/auth-methods.html#KERBEROS-AUTH
BitterGeek
Friday, July 08, 2005
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz