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 ChristopherSchultz. http://wiki.apache.org/tomcat/FAQ/Password?action=diff&rev1=5&rev2=6 -------------------------------------------------- = 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. + 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. + Of course, auditors do not like this answer. So there are some ways to get around this ... + * Use properties replacement so that in the xml config you have ${db.password} and in conf/catalina.properties you put the password there. You are not safer, but the auditors may be happy. - * Since server.xml is an XML file — you can use XML entities. For example: "woot" becomes "&#119;&#111;&#111;&#116;" which is a way to obscure the password. + * Since server.xml is an XML file — you can use XML entities. For example: "woot" becomes "woot" which is a way to obscure the password. * XML entities can be read from an external file. That is, add the following lines at the top of server.xml just above the {{{<Server>}}} element: + {{{ <!DOCTYPE server-xml [ <!ENTITY resources SYSTEM "resources.txt"> ]> }}} - Now, whenever you write {{{&resources;}}} in the text below, it will be replaced by the content of the file "resources.txt". The file path is relative to the conf directory. + . Now, whenever you write {{{&resources;}}} in the text below, it will be replaced by the content of the file "resources.txt". The file path is relative to the conf directory. - * Write your own datasource implementation which wraps your datasource and obscure your brains out. See the docs on how to do this. + * Write your own datasource implementation which wraps your datasource and obscure your brains out ([[http://en.wikipedia.org/wiki/XOR_cipher|XOR]] and [[http://en.wikipedia.org/wiki/ROT13|ROT13]] are great candidates for this since their strength matches the protection you'll actually get). See the docs on how to do this. * Write your own {{{javax.naming.spi.ObjectFactory}}} implementation that creates and configures your datasource. * (Tomcat 7) Write your own {{{org.apache.tomcat.util.IntrospectionUtils.PropertySource}}} implementation to 'decrypt' passwords that are 'encrypted' in catalina.properties and referenced via ${...} in server.xml. You'll need to set the system property {{{org.apache.tomcat.util.digester.PROPERTY_SOURCE}}} to point to your !PropertySource implementation. This won't provide any real security, it just adds another level of indirection - i.e. 'security by obscurity'. - + ---- [[CategoryFAQ]] --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
