tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Smith <>
Subject Re: Encrypting passwords in the connection pool setup
Date Tue, 01 May 2007 16:17:18 GMT
Just to add to this discussion ...

First, let me say I don't think encrypting the password would in any way 
add significantly to tomcat's security or the security of the database.  
What I'm offering is just a possibility from a purely academic 
standpoint.  Two solutions that can be taken separately or together:

1. Public key encrypt the db password:

Generate a public key/private key pair like a self-signed cert.  Encrypt 
your db password with the public key and secure the private key the way 
you would for running SSL/TLS.  Then a modified version of your favorite 
database pooling software would have to accept a new property like 
sslPassword="..."  Easy enough just by extending the DataSource 
implementation and adding a setter for the new property.  The setter 
decrypts the password using the SSL private key.  You could even hand 
the encrypted password to your developers without them being able to 
gain access unless they get a hold of the server's private key.

2. Put the password in a separate file:

Exend the DataSource implementation in your favorite db pooling package 
to have a passwordFile attribute.  Developers are only given the path to 
the password file and do not have direct access (read/write/any) to the 
file.  It's owned by the tomcat process and read only by that user 
similar to an SSL private key.  On the plus side, there's no 
distribution.  Sys admins can change the db password at any time and 
without notice except to let everyone know when the server's being 

Again, just offering it for the ambitious and the paranoid.  I make no 
offers to write code for either of these ideas.


Darren wrote:
>> Why wouldn't we at least store the MD5 hash of the passwords
>> instead of the password in clear text, or use a scheme similar to the
>> Unix /etc/passwd file?
> You've not thought this through.  Tomcat needs to decrypt or somehow 
> have the credentials in cleartext so it can pass them to the database 
> to establish a connection (MD5 is one way).  If it were possible to 
> create the connection with an encrypted password, it would be just as 
> sensitive as the unencrypted version.
>>> Also,  The encryption doesn't have to be full proof, it just needs 
>>> to be a deterrent.  For the most part it is the people with shell 
>>> access that I want to remove the ability to read the passwords 
>>> from.  Sometimes security through obscurity is enough.
> How would this work?  Something like
> <Resource name="jdbc/db" auth="Container" type="javax.sql.DataSource"
>               driverClassName="com.mysql.jdbc.Driver"
>               username="user" obfuscated="true" password="sh7dhkaDaS"
> url="jdbc:mysql://localhost:3306/appraisal?autoReconnect=true" />
> If so, how do you propose to generate the obfuscated password?  Maybe 
> a utility app that ships with the tomcat distribution?  If so a 
> de-obfuscater would appear somewhere on the internet in a very short 
> space of time.
> Don't get me wrong, I'd like to see something done which could improve 
> on the current cleartext situation, but I can't think of a sensible 
> solution that would warrant a developers time.
> Darren
> ---------------------------------------------------------------------
> To start a new topic, e-mail:
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message