[Esapi-user] [OWASP-ESAPI] ESAPI Encryptor

Kevin W. Wall kevin.w.wall at gmail.com
Fri Jan 15 17:39:19 EST 2010


NOTE: Moving this thread to ESAPI-Users list.

fabio.e.cerullo at aib.ie wrote:
> hi guys,
> 
> would it be advisable to use the ESAPI encryptor to encrypt a session ID?

That depends... if your application server does not already provide session
IDs that uses a "cryptographically secure pseudo random number generator" CSPRNG
(http://en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_generator),
then "yes", encrypting the session ID *may* help. (It at least will help
eliminate attacks predicated on predicting the session IDs.) But I don't think
encrypting with ESAPI encryptor would be the best approach.

However, I think it would make more sense to replace whatever is being used to
generate your session IDs with one based on a CSPRNG. (Note: SecureRandom is
such a class.)

If instead you use AES or any other symmetric block ciphe,r then you are
minimally going to have to find a way to share the secret AES encryption
key with all the application servers in your cluster. (Unless you are only
thinking of using this to create a cryptographically secure token in the
same sense that a CSPRNG does.) Also using CSPRNGs that are based on
secure hashes such as SHA1, SHA-256, etc. are much faster than block
ciphers. There are also some in the cryptographic community that the
typical supported cipher modes such as CBC, ECB, OFB, and CFB are not
really suited for use like generation of cryptographically secure
tokens and that modes like CMAC, CBC-MAC, OMAC, etc. should be used instead.
The reasons for this are extremely complicated and hence I shall not cover
them here. If you are interested in that sort of thing, I suggest you post
to a cryptography mailing list or perhaps the sci.crypt USENET group. However,
I do wish to point out that support for such cipher modes supporting message
authentication codes (MACs) are very rare. You certainly will not find them
in the default JCE provider, SunJCE.

> what additional benefits would it bring compared to the current Java AES 
> implementation?
> 
> http://java.sun.com/developer/technicalArticles/Security/AES/AES_v1.html

Only that with doing encryption with the Sun Java APIs (the Java Cryptography
Extensions) require that developers understand all the nuances of cryptography.
They need to know about cipher modes and initialization vectors and padding
schemes and key generation etc. And that's only the beginning.

The other reason is that the ESAPI 2.0 Encryptor greatly simplifies encryption
vs. the standard JCE APIs.

Hope that answers your question. If not, repost to the ESAPI-Users mailing
list. (The OWASP-ESAPI list is only monitoring by a few of us. At some
point soon, Mr. Manico will come along and turn out it's light. :)

-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