tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Tomcat Wiki] Update of "FAQ/Password" by TimFunk
Date Mon, 08 Nov 2010 15:17:26 GMT
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 TimFunk.
http://wiki.apache.org/tomcat/FAQ/Password?action=diff&rev1=6&rev2=7

--------------------------------------------------

  
  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 ...
+ Auditors do not like this answer. In order to please auditors, feel free to do any of the
following. Please be aware, that all of the following are "security by obscurity" and are
not making the Tomcat more secure. But it may allow you to pass an auditors checklist ....
  
-  * 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.
+  * Use properties replacement so that in the xml config you have ${db.password} and in conf/catalina.properties
you put the password there. 
-  * 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.
+  * Since server.xml is an XML file — you can use XML entities. For example: "woot" becomes
"&amp;#119;&amp;#111;&amp;#111;&amp;#116;" which is a way to obscure the password.
You may even go through an extra layer of indirection by converting ${db.password} into XML
entities so that the property replacement above is also performed. (But remember, while "clever,
not more secure)
   * 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:
  
  {{{
@@ -20, +20 @@

   . 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 ([[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'.
+  * (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. 
  
  ----
  [[CategoryFAQ]]

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message