[OWASP-ESAPI] About owasp-esapi-java

Jim Manico jim.manico at owasp.org
Fri May 22 16:58:05 EDT 2009


> 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 
  To: Matthew Presson ; jim.manico at owasp.org ; eric.bing at oracle.com ; owasp-esapi at lists.owasp.org ; Bedirhan Urgun 
  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> 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
  > To: eric.bing at oracle.com; 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>
  > To: <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>
  > >> Subject: Re: [OWASP-ESAPI] About owasp-esapi-java
  > >> To: "Jim Manico" <jim.manico at owasp.org>, <jeffl.williams at owasp.org>,
  > >> "Bedirhan Urgun" <urgunb at hotmail.com>, <owasp-esapi at lists.owasp.org>
  > >> Message-ID:
  > >> <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]
  > >> Sent: Thu 5/21/2009 4:09 PM
  > >> To: Arshan Dabirsiaghi; jeffl.williams at owasp.org; Bedirhan Urgun; 
  > >> 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>
  > >> To: jeffl.williams at owasp.org ; Bedirhan Urgun <mailto:urgunb at hotmail.com> 
  > >> ; 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
  > >> 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
  > >> 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
  > > https://lists.owasp.org/mailman/listinfo/owasp-esapi
  > > 
  > 
  > _______________________________________________
  > OWASP-ESAPI mailing list
  > OWASP-ESAPI at lists.owasp.org
  > https://lists.owasp.org/mailman/listinfo/owasp-esapi


------------------------------------------------------------------------------

  Windows Live™: Keep your life in sync. Check it out.


  _______________________________________________
  OWASP-ESAPI mailing list
  OWASP-ESAPI at lists.owasp.org
  https://lists.owasp.org/mailman/listinfo/owasp-esapi




  -- 
  Matt Presson, CISSP
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-esapi/attachments/20090522/fb9bea84/attachment-0001.html 


More information about the OWASP-ESAPI mailing list