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.
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 "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.
- 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
javax.naming.spi.ObjectFactoryimplementation that creates and configures your datasource. - (Tomcat 7) Write your own
org.apache.tomcat.util.IntrospectionUtils.PropertySourceimplementation to 'decrypt' passwords that are 'encrypted' in catalina.properties and referenced via ${...} in server.xml. You'll need to set the system propertyorg.apache.tomcat.util.digester.PROPERTY_SOURCEto point to your PropertySource implementation. This won't provide any real security, it just adds another level of indirection - i.e. 'security by obscurity'.