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
restarted.
Again, just offering it for the ambitious and the paranoid. I make no
offers to write code for either of these ideas.
--David
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: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
