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

Mike Boberski mike.boberski at gmail.com
Sun Apr 18 12:07:57 EDT 2010

This is tough to discuss over email.

In the abstract I'm pointing out that we need to further abstract
esapi as a wrapper for crypto, not to pull crypyo functions, key
management, etc into esapi. Capture in esapi certain design patterns
like encrypt for data at rest, like associate keys with users, etc.
Crypto is like auth, not likely I'd use esapi's class, but I'd
use/extend the interface. You're trying to subsume the functionality
like encoding, which is not the right thing to do for this type of
control, need to make a sample ref implementation that is easy to
replace. Should always assume you're calling a validated module, not
try to reinvent the blood and guts of this stuff.

Maybe we can talk on the phone some time.

On 4/17/10, Jim Manico <jim.manico at owasp.org> wrote:
> 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


More information about the Esapi-user mailing list