New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Storing encryption keys in a separate key vault #189
Comments
From chrisisbeef on November 20, 2010 13:05:09 Status: Acknowledged |
From kevin.w.wall@gmail.com on December 31, 2010 04:08:21 IMHO, this is more likely to be an enhancement for release 2.2 (or perhaps 3.0) unless we can find a suitable FOSS key management system to use. There are not very many that I've found. This is discussed in more detail in section 4.2 of the "Design Goals in OWASP ESAPI Cryptography" document included with the ESAPI documentation. |
For a while now, ESAPI's If anyone has any objections about closing this, please speak up now. |
Agreed - |
Changed to milestone 2.3 since 2.2.0.0 release already released without addressing this. |
Changing this from milestone 2.3 to 3.0. I'd like to use Hashicorp Vault for this, but I do not want to pull in more direct and transitive dependencies into ESAPI when very few ESAPI clients (probably less than 1%) use the ESAPI Encryptor. |
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:
so file permissions can be different for both.
can gain access to the password.
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.
so file permissions can be different for both.
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.
web servers so only the keys for communication need to be revoked
if a web server gets compromised.
to access the crypto application would have access to the keys.
using the other options. Adding new web servers to use the application
is very easy though.
(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
The text was updated successfully, but these errors were encountered: