Re: Encrypting passwords in the connection pool setup
I commented on this in the following article - http://www.owasp.org/ index.php/Securing_tomcat#Cleartext_Passwords_in_CATALINA_HOME.2Fconf. 2Fserver.xml In short, no. There was also some further discussion on one of the OWASP list recently - https://lists.owasp.org/pipermail/java-project/2007-April/ 000150.html On 30 Apr 2007, at 21:31, Kelly J Flowers wrote: I'm using Tomcat 5.5 to run a web application. I have the connection pools set up and working in the context.xml but the password is in plain text. Does anyone know of a way to encrypt the password and username to the database? - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Encrypting passwords in the connection pool setup
Mark, The ability to store encrypted passwords doesn't necessarily have to be used to protect the system from hackers. This would be a GREAT feature to enforce the responsibilities between different roles in a development environment. 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. Mark Thomas [EMAIL PROTECTED] 4/30/2007 5:30 PM Kelly J Flowers wrote: I'm using Tomcat 5.5 to run a web application. I have the connection pools set up and working in the context.xml but the password is in plain text. Does anyone know of a way to encrypt the password and username to the database? This is nearly always pointless. A couple of points to consider: 1. If the password is encrypted, where do you store the decryption key? 2. If an attacker can read the context.xml file they probably have shell access to your box. In this case you have bigger problems. Mark - 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]
Re: Encrypting passwords in the connection pool setup
Mark, I also don't feel quite at ease to see passwords in clear text in the server.xml file. True, if the protection on that file is set up properly, there shouldn't be much issue. But it strikes me that Tomcat is the only application I know where passwords are stored in clear text. 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? I do agree with Richard that there is more to it than protecting from hackers. Enforcing the responsabilities between different roles is also very important. Martin On 5/1/07, Richard DeGrande [EMAIL PROTECTED] wrote: Mark, The ability to store encrypted passwords doesn't necessarily have to be used to protect the system from hackers. This would be a GREAT feature to enforce the responsibilities between different roles in a development environment. 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. Mark Thomas [EMAIL PROTECTED] 4/30/2007 5:30 PM Kelly J Flowers wrote: I'm using Tomcat 5.5 to run a web application. I have the connection pools set up and working in the context.xml but the password is in plain text. Does anyone know of a way to encrypt the password and username to the database? This is nearly always pointless. A couple of points to consider: 1. If the password is encrypted, where do you store the decryption key? 2. If an attacker can read the context.xml file they probably have shell access to your box. In this case you have bigger problems. Mark - 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] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Encrypting passwords in the connection pool setup
Mark, I've heard that argument before, and it has never made sense to me. If an attacker has read access to one box, that box had better not have passwords for all the other servers in plain text files! Security isn't all-or-nothing. There are levels of security, and you want to get as much security as you reasonably can. Encrypting passwords or hiding them in compiled code certainly raises the bar for someone trying to access something they shouldn't - instead of just reading the password, they'd have to hack the program or break the encryption. Most people don't have the skill to do that. Not all security breaches are caused by genius hackers who know every security hole in every OS. You also have to consider people such as the company insider who searches the network for credit card records he can sell. To put it another way, why do you bother locking the front door of your house? It's completely insecure compared to a bank vault, so why worry about security at all? -- Len On 4/30/07, Mark Thomas [EMAIL PROTECTED] wrote: Kelly J Flowers wrote: I'm using Tomcat 5.5 to run a web application. I have the connection pools set up and working in the context.xml but the password is in plain text. Does anyone know of a way to encrypt the password and username to the database? This is nearly always pointless. A couple of points to consider: 1. If the password is encrypted, where do you store the decryption key? 2. If an attacker can read the context.xml file they probably have shell access to your box. In this case you have bigger problems. Mark - 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]
Re: Encrypting passwords in the connection pool setup
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]
RE: Encrypting passwords in the connection pool setup
Hi, If you want to do something like that you can then extend org.apache.commons.dbcp.BasicDataSourceFactory to encrypt/decrypt the password... And put it in a package jar and put it in common lib and setup the datasource as described in JNDI datasource . Not an easy solution but can be achieved :) Regards Guru -Original Message- From: Darren [mailto:[EMAIL PROTECTED] Sent: 01 May 2007 16:10 To: Tomcat Users List Subject: Re: Encrypting passwords in the connection pool setup 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]
Re: Encrypting passwords in the connection pool setup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Richard, Richard DeGrande wrote: The ability to store encrypted passwords doesn't necessarily have to be used to protect the system from hackers. This would be a GREAT feature to enforce the responsibilities between different roles in a development environment. I solve this problem by using a replaceable set of credentials in the context.xml file (where I set up my connection pool). When I deploy using ant, the values are pulled-in from ~/.ant.properties which can be set per user. In production, the installing user has their own set of credentials. The creds are left out of revision tracking, so mere developers never know the production creds. Also, The encryption doesn't have to be full proof, it just needs to be a deterrent. The point is that encryption such as this only protects against accidental disclosure of a password. The password must be decrypted using a key which is in plain text, so there's no effective security. For the most part it is the people with shell access that I want to remove the ability to read the passwords from. Then make your files readable only by the user under which Tomcat is run. Sometimes security through obscurity is enough. No. Security through obscurity only protects against accidental disclosure among friendly users. There are better ways to achieve this goal (such as using file permissions). The bottom line is that I don't know of any connection pool that supports encrypted passwords in the configuration, so this discussion is entirely academic. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGN2GB9CaO5/Lv0PARAkh7AJ4y+XtFehqMEPsH2N5gxU8pORFxNACcCKni 5gAw3sITPMr0lFhzGwSDHQQ= =C5m4 -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Encrypting passwords in the connection pool setup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin, Martin Dubuc wrote: But it strikes me that Tomcat is the only application I know where passwords are stored in clear text. I'll bet that Tomcat is the only application that needs to know its own passwords. Do you have Apache running with SSL? Where do you store the password for the SSL key? I'll bet that you have a password-less key, which is just about the same as a cleartext password lying around. 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? Because UNIX password files are used to authenticate a user typing their password. In this analogy, Tomcat isn't UNIX, Tomcat is /the user/. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGN2H+9CaO5/Lv0PARAqqrAKDAc7F2rge4Xl0UaND7rhGicN3DYQCdEi4V c9p5LvXt+HudZAMm/98Y3b4= =FqMz -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Encrypting passwords in the connection pool setup
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]
Re: Encrypting passwords in the connection pool setup
Chris, I am not sure I buy your argument that because there is somewhere else in an implementation that is as insecure as cleartext password, then there is no point in fixing the cleartext password issue. With this argument, we would never care about fixing any security holes, because one can always find a new security hole to exploit. Plus, well, the assumption that someone is using a password-less key with Apache running with SSL is pretty weak, because there are ways to avoid using password-less key. As far as the UNIX password analogy, tomcat may be seen as a user, not UNIX, but it still performs authentication. So in my mind, it is filling in for both roles (UNIX and user). I have the impression that using MD5/SHA hashing would be a good option, because it would be simple, would not require any additional key, would provide some sense of security. Not the silverlining, but better than cleartext, for sure. Martin On 5/1/07, Christopher Schultz [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin, Martin Dubuc wrote: But it strikes me that Tomcat is the only application I know where passwords are stored in clear text. I'll bet that Tomcat is the only application that needs to know its own passwords. Do you have Apache running with SSL? Where do you store the password for the SSL key? I'll bet that you have a password-less key, which is just about the same as a cleartext password lying around. 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? Because UNIX password files are used to authenticate a user typing their password. In this analogy, Tomcat isn't UNIX, Tomcat is /the user/. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGN2H+9CaO5/Lv0PARAqqrAKDAc7F2rge4Xl0UaND7rhGicN3DYQCdEi4V c9p5LvXt+HudZAMm/98Y3b4= =FqMz -END PGP SIGNATURE- - 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]
Re: Encrypting passwords in the connection pool setup
Martin, All encryption systems need a way to boot themselves. This either means you store the password somewhere so the program can self-boot itself, or you need user intervention, such as typing in the password (or inserting a dongle or other security hardware device). Once the system has booted itself, then it can store things safely using encryption. A hash value is simply a transformation of one string into another, so if the program that retrieves the password retrieves the real password or its hash, there is no added security, the hash has simply become the password (after all, you cannot go from the hash to the password value, at least not easily with a good hash, as that's it's main reason for being). Hashed passwords are very useful if you have others who will be entering the password in, since you can then store only hashes, and when you need to verify the password entered, you create a hash of the entered password and then compare it to the stored hashed value. This isn't the case for applications that need to bootstrap themselves. You really either need to require manual intervention to start it (and enter the password), or it will be stored in the clear somewhere. David Martin Dubuc wrote: Chris, I am not sure I buy your argument that because there is somewhere else in an implementation that is as insecure as cleartext password, then there is no point in fixing the cleartext password issue. With this argument, we would never care about fixing any security holes, because one can always find a new security hole to exploit. Plus, well, the assumption that someone is using a password-less key with Apache running with SSL is pretty weak, because there are ways to avoid using password-less key. As far as the UNIX password analogy, tomcat may be seen as a user, not UNIX, but it still performs authentication. So in my mind, it is filling in for both roles (UNIX and user). I have the impression that using MD5/SHA hashing would be a good option, because it would be simple, would not require any additional key, would provide some sense of security. Not the silverlining, but better than cleartext, for sure. Martin - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Encrypting passwords in the connection pool setup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin, Martin Dubuc wrote: I am not sure I buy your argument that because there is somewhere else in an implementation that is as insecure as cleartext password, then there is no point in fixing the cleartext password issue. With this argument, we would never care about fixing any security holes, because one can always find a new security hole to exploit. Of course I could never say that security measures are never useful. What I'm saying is that /this/ one isn't (useful). Writing your password on your monitor is a bad idea. Writing it on a sheet of paper in your desk is slightly better, but remembering it is the best solution. I'm asking you to consider looking for the best solution instead of the deployment equivalent of putting your password in your desk drawer. Plus, well, the assumption that someone is using a password-less key with Apache running with SSL is pretty weak, because there are ways to avoid using password-less key. Right. You can either enter the password on startup (a maintenance headache) or you can put the key somewhere (plaintext, I might add). As far as the UNIX password analogy, tomcat may be seen as a user, not UNIX, but it still performs authentication. No, it doesn't. Tomcat is a user of the database. It is never performing database authentication. Tomcat may be performing /user/ authentication, but that unrelated. I have the impression that using MD5/SHA hashing would be a good option, because it would be simple, would not require any additional key, would provide some sense of security. Note that hashing the password is the same as using a plaintext password. I'll leave the reason for this as an exercise for the reader. My belief is that this gives the illusion of security. Bruce Schneier calls this security theater because you are essentially making a symbolic yet meaningless gesture towards security. Please don't hear me saying that what you are proposing is a bad idea, or that security isn't worth it. I'm merely suggesting that there are better ideas than the one you are proposing. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGN3bs9CaO5/Lv0PARAnqYAJ9BCqofhNRgLUcCO8z/ei8momv45wCfahQI J+EbhfxBN+FpWkiqZIRR8rw= =bFGf -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Encrypting passwords in the connection pool setup
I'm using Tomcat 5.5 to run a web application. I have the connection pools set up and working in the context.xml but the password is in plain text. Does anyone know of a way to encrypt the password and username to the database?
Re: Encrypting passwords in the connection pool setup
Kelly J Flowers wrote: I'm using Tomcat 5.5 to run a web application. I have the connection pools set up and working in the context.xml but the password is in plain text. Does anyone know of a way to encrypt the password and username to the database? This is nearly always pointless. A couple of points to consider: 1. If the password is encrypted, where do you store the decryption key? 2. If an attacker can read the context.xml file they probably have shell access to your box. In this case you have bigger problems. Mark - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
