Share This:

Stephen Hawking, referring to the ancient philosophical paradox of infinite regress, writes in his 1988 book "A Brief History of time" (ISBN 978-0-553-05340-1):


A well-known scientist (some say it was Bertrand Russell) once gave a public lecture on astronomy. He described how the earth orbits around the sun and how the sun, in turn, orbits around the center of a vast collection of stars called our galaxy. At the end of the lecture, a little old lady at the back of the room got up and said: "What you have told us is rubbish. The world is really a flat plate supported on the back of a giant tortoise." The scientist gave a superior smile before replying, "What is the tortoise standing on?" "You're very clever, young man, very clever," said the old lady. "But it's turtles all the way down!"


I am occasionally asked (typically after an information assurance or IT security group runs an environment scan) why it is that there are clear text passphrases stored in an Apache Tomcat server.xml files. A common security best practice is to keep secrets, well um, secret. How is it, I am asked, that a passphrase used to unlock a keystore that houses sensitive private keys used for secure HTTPS connections is so clearly visible in a configuration file?


This is a good question and one that has been debated quite a lot. And my honest answer is - we haven't been able to figure out anything that provides more adequate protection. The reality is that when you encrypt data in a way that enables you to retrieve the original value through decryption you need to use a key (or in the case of Apache Tomcat a passphrase that is used to derive a key that encrypts the keystore). The problem is where and how to secure that key? There are a few approaches we could take:

  1. Don't store it. Prompt a person for it every time you need it.
    Problem: this does not scale nor is it automatic. Multiple servers that need to be spun up and/or restarted frequently cannot rely on human interaction.
  2. Encrypt it and store it (a common suggestion).
    Problem: if I encrypt the passphrase I will need to use yet another key. How do I protect this new key? Turtles all the way down...
  3. Scramble / encode / hide it / hardcode the key.
    Problem: Any form of obfuscation will (a) be shared among all installations of our software, and (b) can be discovered through reverse engineering or less nefariously by the original author of said obfuscation telling someone about it. Once the obfuscation is made public (as often happens) it is just as exposed as the original clear text passphrase.
  4. Store it in a secure hardware-based vault.
    Problem: Those are expensive and unless you have invested in one to solve the greater issues of enterprise key and credential management it is likely overkill.


The question then remains: what can you do to protect this clear text passphrase from unauthorized disclosure? There are a set of best practices described both by OWASP and Apache on protecting the server.xml file. The two that I most often recommend are:

  1. Use file level access control or permissions to restrict access to server.xml to the service user running Apache Tomcat.
  2. Monitor server.xml for unauthorized access.


I think most security practitioners will agree that security through obscurity is not a good approach as it provides a false sense of security. However, something about leaving clear text passwords in a configuration file just doesn't feel great either. Have you come up with an approach that gives you the proverbial "warm fuzzies"? I would love to hear about it if you have.