From sebastia...@expectit.at on November 08, 2010 03:36:40

In the current ESAPI implementation, a central encryption key is generated by the JavaEncryptor command line tool and stored in plain in the esapi.properties file:

To calculate these values, you can run:

java -classpath esapi.jar org.owasp.esapi.reference.crypto.JavaEncryptor

Encryptor.MasterKey=

This leaves users with the problem that they cannot separate key management from managing the ESAPI configuration. So there might be too many people with access to this key.

A solution would be to store the key in the key store built into the JVM,
see: http://download.oracle.com/javase/6/docs/api/java/security/KeyStore.html This way, users could manage the keys with tools that they are already familiar with, users could implement their own key store implementation
or that of third party products they use.

The remaining problem is how to store and retrieve the key store password in a secure way (currently, everyone with access to the ESAPI.properties file has also unrestricted access to the key).

There are various options to do this. Here is an incomplete list:

1. Having users enter the password during start up.
2. Pretty secure as the password is never stored anywhere
3. Unattended start up is not possible
4. Hard to implement in a really secure way
5. Saving the password in the ESAPI.properties file
6. Easy to implement and use
7. Everyone with access to the file has also access to the password
8. Saving the password in the source code
9. Easy to implement and use
10. The password is in a different file than the ESAPI.properties file
    so file permissions can be different for both.
11. Everyone with access to the source code or class file
    can gain access to the password.
12. Saving the password in a separate file using a stashing algorithm
    A stashing algorithm hides a password in a file with random data.
    So the mechanism is pretty similar to steganography. An attacker has to know the algorithm to determine the password.
13. Easy to implement and use
14. The password is in a different file than the ESAPI.properties file
    so file permissions can be different for both.
15. Obscuring the password makes it harder for an attacker to find the
    password. Depending of the experience of the hacker,
    it might not be too challenging thought.

Another, more radical change would be to delegate encryption and key management to a different application which could also reside on
a different server/appliance.
In this scenario, only the keys for the communication between the web server and this application would be stored on the web server.

• Key management and encryption of stored data is separated from
  web servers so only the keys for communication need to be revoked
  if a web server gets compromised.
• In depth separation of duties: Only people authorized
  to access the crypto application would have access to the keys.
• Initial installation and configuration is more work than
  using the other options. Adding new web servers to use the application
  is very easy though.
• Crypto application can leak keys due to implementation failures
  (see Bruce Schneier et al.: Practical cryptography). This
  could be mitigated by tokenization in some cases.
  With tokenization, you only get a token instead of
  the encrypted document. When you send this token back to
  the crypto application, you get the decrypted document.

Original issue: http://code.google.com/p/owasp-esapi-java/issues/detail?id=179