Dear Wiki user, You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change notification.
The "FAQ/Password" page has been changed by markt: http://wiki.apache.org/tomcat/FAQ/Password?action=diff&rev1=7&rev2=8 Comment: Add note about how the config file should be protected = Passwords = == Why are plain text passwords in the config files? == - Because there isn't a a good way to "secure" them. When Tomcat needs to connect to a database, it needs the original password. While the password could be encoded, there still needs to be a mechanism to decode it. And since the source to Tomcat is freely available, the attacker would know the decoding method. So at best, the password is obscured - but not really protected. Please see the user and dev list archives for flames wars about this topic. + Because there isn't a a good way to "secure" them. When Tomcat needs to connect to a database, it needs the original password. While the password could be encoded, there still needs to be a mechanism to decode it. And since the source to Tomcat is freely available, the attacker would know the decoding method. So at best, the password is obscured - but not really protected. Please see the user and dev list archives for flames wars about this topic. That said, any configuration file that does contain a password needs to be appropriately secured. That means limiting access to the file to the user that Tomcat process as and root (or the administrator on Windows). In [[http://www.catb.org/~esr/writings/cathedral-bazaar/|The Cathedral and the Bazaar]], Eric S. Raymond recounts a story where his fetchmail users asked for encrypted passwords in the .fetchmailrc file (which is almost identical to the situation posed here with server.xml). He refused [[http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s09.html|using the same arguments posed here]]: encrypting or otherwise obfuscating the password in server.xml does not provide any real security: only "security by obscurity" which isn't actually secure. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
