[Esapi-user] store encyrptor.masterkey encrypted

Jim Manico jim.manico at owasp.org
Mon Feb 1 15:50:58 EST 2010


I think moving the ESAPI properties into a db or (preferably) a 
keystorage mechanism is a great idea - and a /necessary /idea. ESAPI 
will eventually move in this direction. I'm reviewing Keyczar and 
looking at how we can integrate this into ESAPI as one possible 

What you can do today is write your own SecurityConfiguration layer. We 
recently added hooks (in the 2.0 trunk) to let you over-ride our 
security configuration implementation and use your own.

If this path interests you, let us know and we can point you in that 

Jim Manico
OWASP Podcast Host/Producer
OWASP ESAPI Project Manager

> thanks for all these great thoughts.
>   I definitely agree that key management is something ESAPI not 
> supposed to resolve.
>   for critical application, I believe prompting a human to enter the 
> secret (passphase or password to database) is a doable solution for 
> key management.
>   will appreciate if anyone could let me know whether there is any 
> existing implementation that can help ESAPI to load the master secret 
> from either db or java keystore.
> On Sun, Jan 31, 2010 at 9:05 PM, Jeff Williams 
> <jeff.williams at aspectsecurity.com 
> <mailto:jeff.williams at aspectsecurity.com>> wrote:
>     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.
>     --Jeff
>     *From:* esapi-user-bounces at lists.owasp.org
>     <mailto:esapi-user-bounces at lists.owasp.org>
>     [mailto: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 <mailto: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 password.
>       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 database?
>       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.
>       thanks.
>     On Fri, Jan 29, 2010 at 4:56 PM, Kevin W. Wall
>     <kevin.w.wall at gmail.com <mailto:kevin.w.wall at gmail.com>> wrote:
>     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
>     database
>     > or in a flat file but encrypted (where to store the master's
>     master key
>     > 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 to
>     > implement this.
>     Yi,
>     How you do this depends greatly on whether you are using ESAPI 1.4 or
>     2.0.
>     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
>     Encryptor.MasterKey
>     value, is quite simple:
>        String masterKey = ... retrieve from some secure storage ...;
>        byte[] skey = ESAPI.encoder().decodeFromBase64( masterKey );
>        String encryptAlgorithm =
>            ESAPI.securityConfiguration().getEncryptionAlgorithm();
>        SecretKeySpec secretKeySpec = new SecretKeySpec(skey,
>     encryptAlgorithm);
>     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
>     getMasterKey()
>     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.
>     HTH,
>     -kevin
>     --
>     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
> ------------------------------------------------------------------------
> _______________________________________________
> Esapi-user mailing list
> Esapi-user at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/esapi-user

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

More information about the Esapi-user mailing list