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

Kevin W. Wall kevin.w.wall at gmail.com
Sat Apr 17 14:12:27 EDT 2010


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