[OWASP-ESAPI] About owasp-esapi-java

Boberski, Michael [USA] boberski_michael at bah.com
Fri May 22 13:52:08 EDT 2009


We might be talking at cross purposes here.

For posterity, the reason why I jumped into this thread, was just to clarify a couple of the points:

A password-derived key can't be "strengthened".

Use a salt that is unique to that account (e.g., internal user ID, account creation) when hashing account passwords. Use RNGs for random numbers, random file names, random GUIDs, and random strings.

For both NIST and ASVS, you'll have to look within the documents that are available on those web sites. FIPS 140 is a mature program, as is NIAP/NSA CC, which relies on the FIPS 140 program to meet its crypto functional requirements.

For NIST, perhaps the "IG" (implementation guidance) would be an interesting read. For ASVS, check out the detailed verification requirements.

Mike B.
 

-----Original Message-----
From: lucas.ferreira at gmail.com [mailto:lucas.ferreira at gmail.com] On Behalf Of Lucas Ferreira
Sent: Friday, May 22, 2009 1:32 PM
To: Boberski, Michael [USA]
Cc: Matthew Presson; owasp-esapi at lists.owasp.org
Subject: Re: [OWASP-ESAPI] About owasp-esapi-java

On Fri, May 22, 2009 at 14:06, Boberski, Michael [USA] <boberski_michael at bah.com> wrote:
> The study of cryptographic hashes is pretty advanced at present.
>
> Perhaps check out the NIST CMVP/CAVP web site, and referenced documents and standards.

Checked the site and saw a lot of information on validating implementation of algorithms but none on the composition of hash functions, which includes iterating the algorithm multiple times.

>
> Perhaps also check out OWASP ASVS.

Have not found any mention to hash function composition on the ASVS web site. Please be more specific.

>
> The short version, regardless:
>
> If you store hashed passwords to use for authentication purposes, make sure to salt the hash.
>
> If you are generating cryptographic keys, use RNGs, do not derive keys from passwords period. Or, if for some reason you're implementing a network protocol, use something like Diffie-Hellman to establish a session key that can be used to encrypt traffic.
>

I doon' t see how salting and the generation of keys relate to hash function composition. To be more precise, we are discussing if iterating a hash function makes it more os less secure then aplying it only one time. This is similar to the composition of ciphers, as used in 3DES, which is an iteration of the DES cipher.

My point is similar to Bruce Schneier's: "Hash functions are the most commonly used cryptographic primitive, and the most poorly understood." (http://www.schneier.com/blog/archives/2008/12/more_sha-3_news.html).
We need more work to understand hash functions, and that include their composition or iteration.

Regards,

Lucas

> Mike B.
>
>
> -----Original Message-----
> From: owasp-esapi-bounces at lists.owasp.org 
> [mailto:owasp-esapi-bounces at lists.owasp.org] On Behalf Of Lucas 
> Ferreira
> Sent: Friday, May 22, 2009 12:15 PM
> To: Matthew Presson
> Cc: owasp-esapi at lists.owasp.org
> Subject: Re: [OWASP-ESAPI] About owasp-esapi-java
>
> Matt,
>
> as far as I know, there are no conclusive results on the composition of hash functions, but I never heard this theory of decrease in the security by composing them.
>
> The study of hash functions will certainly advance due to the NIST competition to define the new US standard hash function, so we better wait to have meaningful results before concluding anything on this topic.
>
> Regards,
>
> Lucas
>
> On Fri, May 22, 2009 at 09:53, Matthew Presson <matthew.presson at gmail.com> wrote:
>> 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.c
>>> > >> o
>>> > >> m>
>>> > >> 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/20090
>>> > >> 5
>>> > >> 21/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(tm): 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
>>
>> _______________________________________________
>> OWASP-ESAPI mailing list
>> OWASP-ESAPI at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/owasp-esapi
>>
>>
>
>
>
> --
> If a tree falls in the forest and no one is around to see it, do the other trees make fun of it?
> _______________________________________________
> OWASP-ESAPI mailing list
> OWASP-ESAPI at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-esapi
>



--
If a tree falls in the forest and no one is around to see it, do the other trees make fun of it?


More information about the OWASP-ESAPI mailing list