[Esapi-user] store encyrptor.masterkey encrypted

Yi Li yi.li26 at gmail.com
Mon Feb 1 20:30:41 EST 2010

Jim, thanks.
will appreciate if you could point me on how to write my own
securityConfiguration with the hook.
I would go with the solution to store the properties in a db.
As a thought, databases today support authentication with OS credentials
(such as sql server). then this could be a solution for the key management:
run ESAPI in the context of an OS account, which can authenticate into the
db.  then the OS will do the dirty work of maintaining the OS account

On Mon, Feb 1, 2010 at 3:50 PM, Jim Manico <jim.manico at owasp.org> wrote:

>  Yi,
> 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 implementation.
> 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
> direction.
> --
> Jim Manico
> OWASP Podcast Host/Producer
> OWASP ESAPI Project Managerhttp://www.manico.net
> 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> 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] *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
>> 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>
>> 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 listEsapi-user at lists.owasp.orghttps://lists.owasp.org/mailman/listinfo/esapi-user
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/esapi-user/attachments/20100201/511e1545/attachment.html 

More information about the Esapi-user mailing list