[Esapi-user] [Esapi-dev] ESAPI 2.0 crypto documentation

Jim Manico jim.manico at owasp.org
Sat Apr 17 18:58:32 EDT 2010


I still think this is only a half solution at best. By storing a  
parial key in the user object, we are now forcing a specific kind of  
encryption and key strength. I think all keys should be pushed to a  
vault in their entirety. That way you can change encryption algorithms  
and key strengths as well as doing audit features within the vault.  
Storing partial keys seems like a partial solution. Ok for ESAPI 2.0  
as an intersticial solution, but by no means is such a method the best  
path.

Jim Manico

On Apr 17, 2010, at 8:12 AM, "Kevin W. Wall" <kevin.w.wall at gmail.com>  
wrote:

> Jim Manico wrote:
>> Mike,
>>
>> Sorry for the short replies - I'm on my mobile and on the run.
>>
>> I do not think we want to save crypto keys in the user object - or
>> anywhere in the app at all. It defeats the purpose of crypto storage,
>> especially when trying to defend again insider threat agents.
>>
>> Crypto Keys, IMO, should be stored in a key vault. We also need to
>> consider the more difficult aspects of crypto storage such as
>> 'asychronous' key rotation (key rotation outside of any user  
>> activity).
>
> Mike, correct me if I'm wrong, but I don't think that Mike was  
> necessarily
> proposing the (permanent) storage of crypto keys in with user object  
> (storage).
> There are other ways to accomplish the same thing that does not  
> require this
> but still allows the user keys to have a relatively high degree of  
> security.
>
> I think what he is proposing, and what I am in favor of, is to allow
> the ability to allow cryptographic keys to be associated with each
> authenticated user. This then allows each user's sensitive or PII
> data to be encrypted independently of other users. So, if an attacker
> is able to steal a DB of encrypted SSNs, CC#s, or other PII, that
> attacker would have to get their hands on N multiple keys before they
> can decrypt everything.
>
> The way that I've envisioned this is that the individual user's PII
> and other sensitive data would be encrypted with a user key. There
> are then two approaches to this. One is to store these keys in a
> key vault and encrypt them with something like PKCS#5 (password-based
> encryption). This only works when there is a reasonably strong  
> password
> policy enforced though, since left to their own, most users don't wish
> to be bothered with passwords. The other variation that I like
> doesn't even require to you to store the user key in a key vault at
> all. Instead, the user key gets stored with the user profile and gets
> encrypted with a combination of some application key and a key based
> on the user's password. Obviously if a user's password is changed,
> then this user key needs to be decrypted and re-encrypted accordingly.
>
> If the encrypted user data is something that a company must be able
> to retrieve and decrypt (say for law enforcement) then the user
> keys can use this combination of application key and user password
> in such a way that affectively allows for key escrow.  I don't think
> any of these approaches are novel (at least to the cryptographic
> community), but they are not things that are generally employed
> with standard IT applications. Specifically, if one needs to be
> able to search on something like (say) a CC#, you need an alternate
> way to do this, such as keeping a secure hash of it or only storing
> the last 4 digits, etc.  I could sketch out a more detailed design
> of how I've envisioned this if that would be helpful.
>
> -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


More information about the Esapi-user mailing list