Stephan van Hulst wrote:This sounds like a terrible practice to me. Can you point out specifically where it says that you should encrypt the password?
Kris Thomson wrote:I'm sure Google, Amazon, etc. who use tomcat would never have this file with an un-encrypted password on their production system.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
Stephan van Hulst wrote:
Kris Thomson wrote:I'm sure Google, Amazon, etc. who use tomcat would never have this file with an un-encrypted password on their production system.
And there I think you would be mistaken. Do you have any reason at all to believe that this password should be encrypted? Can you point me to any publication that makes a compelling argument for this practice?
Encrypting passwords on systems where only administrators should have access to in the first place is a sure indication of a fundamental misunderstanding of security concepts.
Encrypting passwords on systems where only administrators should have access to in the first place is a sure indication of a fundamental misunderstanding of security concepts.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
Kris Thomson wrote:non-plain text for tomcat users
Encrypting passwords on tomcat
to name a few. thanks.
Tim Holloway wrote:Not so. Otherwise we'd still be using plaintext /etc/passwd files in Unix and Linux.
Cleartext Passwords in CATALINA_HOME/conf/server.xml
When configuring a resource, such as a JDBC pool, it is necessary to include clear text username and password in CATALINA_HOME/conf/server.xml Best practices advice us never to store clear text passwords, but the following paragraphs highlight it is very difficult to avoid.
If one way encryption was used on the password it must be possible for a database connection to be established using a username and encrypted password - so the encrypted password is just as valuable as the clear text one to an attacker.
If two way encryption was used a keyfile is needed which must also live on the filesystem. To make it more secure a passphase is added to the keyfile which then has to be stored in the configuration as clear text - no improvement.
Encoding is security by obscurity and offers no form of protection (algorithms can be reverse engineered). What encoding does do is make huge amounts of overhead work - you need to customise Tomcat and the commons digester it uses to parse the config files. You'd also need a way to create encoded passwords.
In the case of a JDBC pool what you can do is;
make sure the database user only has access to the databases and tables they need (also limit rights as necessary). make sure the raw database files are only accessible to the user running the database services (e.g. mysql/postgresql user) make sure the Tomcat configuration files are only accessible to the tomcat user
Stephan van Hulst wrote:You can't do the same thing with server passwords, because at some point the manager app needs it in plain text.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
Tim Holloway wrote:Hashing is less secure than encryption for passwords, but it's faster, especially when you don't allow reading of the password.
Gravity is a harsh mistress. But this tiny ad is pretty easy to deal with:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
|