[Esapi-dev] jscrypto

Boberski, Michael [USA] boberski_michael at bah.com
Mon Jan 25 13:34:59 EST 2010


I only have one question (challenge!) to all ESAPI folks implementing AND using crypto, regardless of language or library:

Show me the key management policy!!

Find all the keys you're using, figure out where they came from, who may have access to what keys using what interfaces, how they're being used (algorithm/mode/keysize, and for what data which is how sensitive), and under what circumstances and how they're destroyed.

The "challenge" is tongue in cheek of course, please don't start sending me policy documents. The point: you'll quickly figure out what's OK w.r.t. your individual application's/organization's policies (and/or your ESAPI implementation), and what's not, taking this kind of an approach. Rock on with client-side crypto if e.g. you're signing something with keys loaded from a smart card, or doing public key encryption, many other examples...

FWIW, <-- please the acronymn read twice, I'm offering help, for which folks paid $0.00 :-)

Best,

Mike B.


________________________________
From: esapi-dev-bounces at lists.owasp.org [mailto:esapi-dev-bounces at lists.owasp.org] On Behalf Of Chris Schmidt
Sent: Monday, January 25, 2010 1:13 PM
To: Jeremy Long
Cc: ESAPI-Developers
Subject: Re: [Esapi-dev] jscrypto

"it is providing something that will make people think they are adding security, but 9.99999999 times out of 10 it is only adding more overhead and complexity without adding any security"

I think the same could be said about any encryption framework in the world, but the general thinking here is that there are legitimate uses for client side encryption and as such the concept lives under the domain of the ESAPI. The fact that it would be an *optional* component is also important, as most people will not have a lot of use for encryption in the JS code of their application.

Also important is to note that the issue of MiTM is an entirely different issue altogether. There is definite benefit in the ability to encrypt and decrypt data transmitted over the wire as part of a json object and such transmissions should take place over SSL and be accompanied by a digital signature on the json string itself (seperate thread). There will likely be a 'Best-Practices' guide that accompanies the ESAPI4JS and highlights some of these use-cases and the *correct* way to implement them using ESAPI4JS.

I am currently looking at http://www.clipperz.com/open_source/javascript_crypto_library as the possible library to be the reference implementation of the cryptography component. Jeff, if you are around could you take a look at the license for this toolkit and verify that it is compatible with the BSD license we use for ESAPI?



On Mon, Jan 25, 2010 at 7:14 AM, Jeremy Long <jeremy.long at gmail.com<mailto:jeremy.long at gmail.com>> wrote:
I've seen crypto implemented in the browser before.  Here is on implementation of a RSA: http://www.leemon.com/crypto/BigInt.html

"It's hard to imagine any practical cryptographic use for this code, other than pedagogical. As of 2009, the major browsers give warning messages if it runs more than a few seconds. A web page is susceptible to Man In The Middle (MITM) attacks. A MITM can modify a web page as it's downloading, inserting code to capture passwords etc. as they're typed, and send them back to the MITM. Even SSL adds little security, since users ignore certificate warnings. This page was just written for my entertainment, after seeing a request<http://groups.google.com/group/sci.crypt/browse_thread/thread/f99306bb3fef3f26?hl=en> for something like this on sci.crypt. "

The above quote is from the bottom of the page I provided a link to.  I would strongly discourage adding a crypto implementation to the JS side of the ESAPI - it is providing something that will make people think they are adding security, but 9.99999999 times out of 10 it is only adding more overhead and complexity without adding any security.

For instance, look at http://enanocms.org/features.  One of their claims is that they use a Diffie Hellman Key exchange (i.e. JavaScript in browser <-> Server) to increase security...  Diffie Hellman Key exchange is vulnerable to a MiTM attack - unless you are doing this key exchange over SSL you have an issue, if you are transmitting over SSL you do not need the added key exchange.  Thus, added complexity without much reward.

--Jeremy

On Mon, Jan 25, 2010 at 1:29 AM, Chris Schmidt <chrisisbeef at gmail.com<mailto:chrisisbeef at gmail.com>> wrote:
I would like some community input on implementing an optional crypto api for ESAPI4JS. This would not be part of the *core* esapi4js framework, but it seems like it could be somewhat useful as an add-on.

http://crypto.stanford.edu/sjcl/#paper

Kevin, I am definitely looking for your input here, being the local crypto guru. :)


--
-- Chris

OWASP ESAPI Developer
http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API

Check out OWASP ESAPI for Java
http://code.google.com/p/owasp-esapi-java/

Coming soon OWASP ESAPI for JavaScript
http://code.google.com/p/owasp-esapi-js/

_______________________________________________
Esapi-dev mailing list
Esapi-dev at lists.owasp.org<mailto:Esapi-dev at lists.owasp.org>
https://lists.owasp.org/mailman/listinfo/esapi-dev





--
Chris Schmidt

OWASP ESAPI Developer
http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API

Check out OWASP ESAPI for Java
http://code.google.com/p/owasp-esapi-java/

OWASP ESAPI for JavaScript
http://code.google.com/p/owasp-esapi-js/

Yet Another Developers Blog
http://yet-another-dev.blogspot.com

Bio and Resume
http://www.digital-ritual.net/resume.html

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/esapi-dev/attachments/20100125/899b4f6c/attachment-0001.html 


More information about the Esapi-dev mailing list