[OWASP-ESAPI] About owasp-esapi-java

Neil Matatall nmatatal at uci.edu
Fri May 22 17:18:56 EDT 2009


Wouldn't a salt that is predetermined defeat the purpose of the salt?  
However, storing the salt will add some complexity to the API.

Neil

Jim Manico wrote:
> > This is interesting revelation to me, because it generalizes to the 
> fact that today’s attackers now have the upper hand in all data 
> processing capabilities.
>  
> Insightful post, flipping my "hardware is cheap" argument is really 
> appropriate. Interesting.
>  
> Could moving to a "better hash" help us here with ESAPI? Is there 
> anything stronger than SHA-2 that is usable?
>  
> What about salting, there are ways to get pretty crazy with salt 
> generation and storage. Right now the ESAPI salt is the account name - 
> should that be a cryptographically random string? What about storage 
> of the salt, should we recommend some kind of database level 
> protection or schema separation of the salt?
>  
> - Jim
>  
> > An attacker could cloudsource his hash cracking operation to A3 or a 
> botnet and defeat the .001 multiplication the iterations provide very 
> easily.
>  
> Totally. An attacker can also buy a few playstation 3's or few PC's 
> and with FOSS cluster software have a pretty cracking machine, without 
> even leverging cloud services.
>  
>
>     ----- Original Message -----
>     *From:* Arshan Dabirsiaghi
>     <mailto:arshan.dabirsiaghi at aspectsecurity.com>
>     *To:* Matthew Presson <mailto:matthew.presson at gmail.com> ;
>     jim.manico at owasp.org <mailto:jim.manico at owasp.org> ;
>     eric.bing at oracle.com <mailto:eric.bing at oracle.com> ;
>     owasp-esapi at lists.owasp.org <mailto:owasp-esapi at lists.owasp.org> ;
>     Bedirhan Urgun <mailto:urgunb at hotmail.com>
>     *Sent:* Friday, May 22, 2009 5:06 AM
>     *Subject:* RE: [OWASP-ESAPI] About owasp-esapi-java
>
>     I see what you mean, but I don’t think it hurts us much.
>
>      
>
>     Technically, it’s true that an attacker has 999 more target hashes
>     than a traditional hashing workflow if they’re attempting a
>     birthday-style attack. The problem with that scenario here is the
>     attacker would have no idea if he landed on one of those values
>     unless he iterated the hash over it at minimum (of a miss) 998
>     more times to confirm it, which was our original intention anyway.
>     I’m no cryptographer, so it’s all too possible that my logic here
>     is flawed.
>
>      
>
>     The offline hash cracking through rainbow tables or brute force is
>     what the mechanism is intended is to defeat, but I think that
>     utilizing a properly random salt is doing our due diligence. After
>     all, as Jim pointed out elsewhere, hardware is cheap. An attacker
>     could cloudsource his hash cracking operation to A3 or a botnet
>     and defeat the .001 multiplication the iterations provide very
>     easily.
>
>      
>
>     This is interesting revelation to me, because it generalizes to
>     the fact that today’s attackers now have the upper hand in all
>     data processing capabilities.
>
>      
>
>     Arshan
>
>      
>
>      
>
>      
>
>     *From:* owasp-esapi-bounces at lists.owasp.org
>     [mailto:owasp-esapi-bounces at lists.owasp.org] *On Behalf Of
>     *Matthew Presson
>     *Sent:* Friday, May 22, 2009 8:53 AM
>     *To:* jim.manico at owasp.org; eric.bing at oracle.com;
>     owasp-esapi at lists.owasp.org; Bedirhan Urgun
>     *Subject:* Re: [OWASP-ESAPI] About owasp-esapi-java
>
>      
>
>     I have heard from varying sources that hashing something multiple
>     times does not actually increase security at all.  In many cases I
>     have heard that it actually decreases security due to the
>     potential to increase the possibility of a collision.
>
>     Any thoughts on this?
>
>
>     -Matt
>
>     On Fri, May 22, 2009 at 12:10 AM, Bedirhan Urgun
>     <urgunb at hotmail.com <mailto:urgunb at hotmail.com>> wrote:
>
>
>     I agree with the idea that "as long as it is configurable
>     everything is cool". It's not the case right now in 1.4.x but
>     fixed. Thanks.
>     One of our key goals was to have a faster mvc implementation
>     and currently we use the hash method to produce a CSRF token
>     (being aware that are other ways). So we might just stick to 1 as
>     a default value.
>      
>     cheers,
>     bedirhan
>      
>     > From: jim.manico at owasp.org <mailto:jim.manico at owasp.org>
>     > To: eric.bing at oracle.com <mailto:eric.bing at oracle.com>;
>     owasp-esapi at lists.owasp.org <mailto:owasp-esapi at lists.owasp.org>
>     > Date: Thu, 21 May 2009 11:12:08 -1000
>
>
>     > Subject: Re: [OWASP-ESAPI] About owasp-esapi-java
>     >
>     > > I think the most important point is that I can override
>     whatever value
>     > > is set for a particular use case. I haven't looked at the APIs
>     here, so
>     > > I'm not sure if that's the case.
>     >
>     > Yea, I see the light. I think you are right on here Eric (and
>     Arshan).
>     >
>     > Perhaps we should expose HashIterations at the API level so
>     programmers can
>     > make their own call as to the # of hash iterations, and default
>     this to 1
>     > which is the expected hash level?
>     >
>     > I can see where different use cases merit different iteration
>     numbers, and
>     > defaulting to 1 which is the expected hash behaviour, does seems
>     reasonable
>     > to me.
>     >
>     > But for all my apps, I'm setting it to 1024 :)
>     >
>     > - Jim
>     >
>     > ----- Original Message -----
>     > From: "eric bing" <eric.bing at oracle.com
>     <mailto:eric.bing at oracle.com>>
>     > To: <owasp-esapi at lists.owasp.org
>     <mailto:owasp-esapi at lists.owasp.org>>
>     > Sent: Thursday, May 21, 2009 10:59 AM
>     > Subject: Re: [OWASP-ESAPI] About owasp-esapi-java
>     >
>     >
>     > >I tend to agree with Arshan on this one. There are certainly cases
>     > > (password or credit card hashes) where the retention time and
>     small name
>     > > space make this essential, but there are a lot of other cases
>     (session
>     > > hashing) where its not. Given that both use cases exist, my naive
>     > > assumption going into the library is that its only being run
>     once. On
>     > > the other hand, its legitimate to argue that you want to
>     default to a
>     > > more secure configuration.
>     > >
>     > > I think the most important point is that I can override
>     whatever value
>     > > is set for a particular use case. I haven't looked at the APIs
>     here, so
>     > > I'm not sure if that's the case.
>     > > -Eric
>     > >
>     > >> Date: Thu, 21 May 2009 16:23:36 -0400
>     > >> From: "Arshan Dabirsiaghi"
>     <arshan.dabirsiaghi at aspectsecurity.com
>     <mailto:arshan.dabirsiaghi at aspectsecurity.com>>
>     > >> Subject: Re: [OWASP-ESAPI] About owasp-esapi-java
>     > >> To: "Jim Manico" <jim.manico at owasp.org
>     <mailto:jim.manico at owasp.org>>, <jeffl.williams at owasp.org
>     <mailto:jeffl.williams at owasp.org>>,
>     > >> "Bedirhan Urgun" <urgunb at hotmail.com
>     <mailto:urgunb at hotmail.com>>, <owasp-esapi at lists.owasp.org
>     <mailto:owasp-esapi at lists.owasp.org>>
>     > >> Message-ID:
>     > >>
>     <B9A412898630124ABE8350F4EBD32E84F437BE at mymail.aspectsecurity.com
>     <mailto:B9A412898630124ABE8350F4EBD32E84F437BE at mymail.aspectsecurity.com>>
>     > >> Content-Type: text/plain; charset="iso-8859-1"
>     > >>
>     > >> Of course it is.
>     > >>
>     > >> I'm saying most people, if they knew that this was going on,
>     would choose
>     > >> not to use it because of the limited benefits it provides.
>     It's possible
>     > >> that I'm wrong - I have no data to support that opinion. I
>     just know lots
>     > >> of developers who generally like things to be really fast.
>     > >>
>     > >> Arshan
>     > >>
>     > >> ________________________________
>     > >>
>     > >> From: Jim Manico [mailto:jim.manico at owasp.org
>     <mailto:jim.manico at owasp.org>]
>     > >> Sent: Thu 5/21/2009 4:09 PM

>     > >> To: Arshan Dabirsiaghi; jeffl.williams at owasp.org
>     <mailto:jeffl.williams at owasp.org>; Bedirhan Urgun;
>     > >> owasp-esapi at lists.owasp.org <mailto:owasp-esapi at lists.owasp.org>
>     > >> Subject: Re: [OWASP-ESAPI] About owasp-esapi-java
>     > >>
>     > >>
>     > >> Arshan,
>     > >>
>     > >> The slowness is by design, intending to make it slower for
>     someone with
>     > >> database access to brute-force the hash back to the password.
>     > >>
>     > >> - Jim
>     > >>
>     > >>
>     > >> ----- Original Message -----
>     > >> From: Arshan Dabirsiaghi
>     <mailto:arshan.dabirsiaghi at aspectsecurity.com
>     <mailto:arshan.dabirsiaghi at aspectsecurity.com>>
>     > >> To: jeffl.williams at owasp.org
>     <mailto:jeffl.williams at owasp.org> ; Bedirhan Urgun
>     <mailto:urgunb at hotmail.com <mailto:urgunb at hotmail.com>>
>     > >> ; owasp-esapi at lists.owasp.org
>     <mailto:owasp-esapi at lists.owasp.org>
>     > >> Sent: Thursday, May 21, 2009 10:05 AM
>     > >> Subject: Re: [OWASP-ESAPI] About owasp-esapi-java
>     > >>
>     > >> The HashIterations value is a form of key strengthening [1].
>     Am I alone
>     > >> in thinking this value should be 1 (essentially off) by
>     default? I'm not
>     > >> suggesting hashing is expensive as search, but I think people
>     would not
>     > >> like the performance results of this feature. After all, it's
>     intended to
>     > >> be slow.
>     > >>
>     > >> Arshan
>     > >>
>     > >> [1] http://en.wikipedia.org/wiki/Key_strengthening
>     > >>
>     > >> ________________________________
>     > >>
>     > >>
>     > >>
>     > >> 4. There's a HashIterations property key in ESAPI.properties.
>     But this
>     > >> isn't used in org.owasp.esapi.reference.JavaEncyptor's hash
>     method.
>     > >> Instead there's a hardcoded 1024.
>     > >>
>     > >>
>     > >>
>     > >> Good catch. This has been fixed so the hash iterations are
>     configurable
>     > >> now. Thanks!
>     > >>
>     > >>
>     > >>
>     > >> --Jeff
>     > >>
>     > >>
>     > >>
>     > >>
>     > >> ________________________________
>     > >>
>     > >>
>     > >>
>     > >>
>     > >> _______________________________________________
>     > >> OWASP-ESAPI mailing list
>     > >> OWASP-ESAPI at lists.owasp.org <mailto:OWASP-ESAPI at lists.owasp.org>
>     > >> https://lists.owasp.org/mailman/listinfo/owasp-esapi
>     > >>
>     > >>
>     > >> -------------- next part --------------
>     > >> An HTML attachment was scrubbed...
>     > >> URL:
>     > >>
>     https://lists.owasp.org/pipermail/owasp-esapi/attachments/20090521/40e3de6d/attachment.html
>     > >>
>     > >> ------------------------------
>     > >>
>     > >> _______________________________________________
>     > >> OWASP-ESAPI mailing list
>     > >> OWASP-ESAPI at lists.owasp.org <mailto:OWASP-ESAPI at lists.owasp.org>
>     > >> https://lists.owasp.org/mailman/listinfo/owasp-esapi
>     > >>
>     > >>
>     > >> End of OWASP-ESAPI Digest, Vol 20, Issue 8
>     > >> ******************************************
>     > >>
>     > > _______________________________________________
>     > > OWASP-ESAPI mailing list
>     > > OWASP-ESAPI at lists.owasp.org <mailto:OWASP-ESAPI at lists.owasp.org>
>     > > https://lists.owasp.org/mailman/listinfo/owasp-esapi
>     > >
>     >
>     > _______________________________________________
>     > OWASP-ESAPI mailing list
>     > OWASP-ESAPI at lists.owasp.org <mailto:OWASP-ESAPI at lists.owasp.org>
>     > https://lists.owasp.org/mailman/listinfo/owasp-esapi
>
>     ------------------------------------------------------------------------
>
>     Windows Live™: Keep your life in sync. Check it out.
>     <http://windowslive.com/explore?ocid=TXT_TAGLM_BR_life_in_synch_052009>
>
>
>     _______________________________________________
>     OWASP-ESAPI mailing list
>     OWASP-ESAPI at lists.owasp.org <mailto:OWASP-ESAPI at lists.owasp.org>
>     https://lists.owasp.org/mailman/listinfo/owasp-esapi
>
>
>
>
>     -- 
>     Matt Presson, CISSP
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> OWASP-ESAPI mailing list
> OWASP-ESAPI at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-esapi
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-esapi/attachments/20090522/49f22b39/attachment-0001.html 


More information about the OWASP-ESAPI mailing list