[Esapi-user] store encyrptor.masterkey encrypted

Jeff Williams jeff.williams at aspectsecurity.com
Sun Jan 31 21:05:02 EST 2010

Hi Yi,


>  it seems to introduce another weakness.

The weakness is there no matter what you do - and has nothing to do with
ESAPI.  The application has to have a 'master' secret that it can access
without relying on some other secret.  You could have a human put this
key into a running application, but then it won't be able to restart
itself without human intervention.


The ESAPI approach is to acknowledge this problem and not play
obfuscation games that are likely to end up introducing mistakes that
reduce security. Protect the ESAPI configuration file with operating
system controls.




From: esapi-user-bounces at lists.owasp.org
[mailto:esapi-user-bounces at lists.owasp.org] On Behalf Of Yi Li
Sent: Saturday, January 30, 2010 8:58 PM
To: Kevin W. Wall
Cc: esapi-user at lists.owasp.org
Subject: Re: [Esapi-user] store encyrptor.masterkey encrypted


Kevin, chris:
  thanks for the great reply. I am using ESAPI 2.0.
  If I fetch the master key from a database, then the application would
need to be able to connect to a database, which would require a login
  it seems that I have to store the username/password to the database in
a clear text conf file so that the application could load and connect to
  it seems to introduce another weakness.
  this is a question on how we could use ESAPI and in the mean time have
a secure key management. 
  it would be great if you could share your insight.

On Fri, Jan 29, 2010 at 4:56 PM, Kevin W. Wall <kevin.w.wall at gmail.com>

Yi Li wrote:
> greetings, all:
>     will appreciate if anyone could provide insight here.
>     I would like to store the master encryption key
> (encryptor.masterkey) with some sort of protection, instead of keeping
> it clear text in the properities file even though i can place access
> control via the file system.
>    i am thinking to either store the encryption key either in a
> or in a flat file but encrypted (where to store the master's master
> become another problem to solve).
>    will appreciate if anyone could point me to an implementation that
> will support this or point me the way to write my own implementation
> implement this.


How you do this depends greatly on whether you are using ESAPI 1.4 or

If you are using 2.0 and concerned about it, your best course of action
would be to retrieve it from wherever you wish to store it (e.g., TPM,
HSM, database, etc.) and then use the encrypt / decrypt methods that
take a secret key, i.e.,

       public interface Encryptor {
               CipherText encrypt(SecretKey key, Plaintext plaintext)
                       throws EncryptionException;
               PlainText decrypt(SecretKey key, CipherText ciphertext)
                       throws EncryptionException;

The way you calculate this SecretKey value, given the
value, is quite simple:

   String masterKey = ... retrieve from some secure storage ...;
   byte[] skey = ESAPI.encoder().decodeFromBase64( masterKey );
   String encryptAlgorithm =
   SecretKeySpec secretKeySpec = new SecretKeySpec(skey,

and then use secretKeySpec for the SecretKey parameter on the above
encrypt / decrypt methods.

OTOH, if you are using ESAPI 1.4.x, then I'm afraid that this is going
to be much harder. It does not have such encrypt / decrypt methods so it
can only use the single key. The value of this property is retrieved and
base64-decoded by the reference encrypt/decrypt Encryptor implementation
using ESAPI.securityConfiguration().getMasterKey(), so you would need
to write your SecurityConfiguration implementation and change
to retrieve the master key from whatever secure data store you wish
to keep it in. You would then have to call
ESAPI.setSecurityConfiguration(new MySecurityConfigurationImpl())
before you encrypt/decrypt with this. You could write your own
SecurityConfiguration implementation by either wrapping (delegation)
or extending DefaultSecurityConfiguration and then change getMasterKey()
to act differently.

I might be missing some of the details, which I' sure others will
correct, but I think this is the guts of it.

Kevin W. Wall
"The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents."        -- Nathaniel Borenstein, co-creator of MIME


-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/esapi-user/attachments/20100131/aa5523c5/attachment.html 

More information about the Esapi-user mailing list