[Owasp-leaders] [Esapi-dev] How to store a password

Jim Manico jim.manico at owasp.org
Fri Feb 18 20:00:44 EST 2011


> Did I miss something? Or maybe your own
> conclusion? I'm kind of interested in that part, see. :)

Ok then :) My conclusion is:

Hash ITERATION accomplishes the same thing (slow down the attackers custom rainbow tables) as bcrypt's WORK FACTOR. Either methods works as a decent low-risk password storage mechanism

So to sum up we need, in my opinion, 4 mechanisms to safely store a password:

1) Strong hash (bcrypt or sha2(512))
2) Utilize hash iterations (sha2) or a work factor (brcypt) to slow down the attacker. Today, I recommend 100,000 iterations of SHA2 (per jsypt); but we should increment that recommended number ever year per moores law (and implementations should be able to do hash migration over time).
3) I still think we should use a cryptographically random salt, but I'm not sure what size to recommend. Time to do a little manual math labor soon.
4) I also recommend salt isolation (ie: something along the lines of keeping hashes in DB and salts in a file system or different schema)

Secure Remote Password is new to me, I'll check it out John.

Keep in mind that PBKDF2 handles 1-3 for you. :) http://en.wikipedia.org/wiki/PBKDF2

But then again, we are all moving to multi-factor authN anyhow, right? ;)

Cheers all + thank you,
Jim





> Let's not forget about Stanford's alternative called Secure Remote Password:
> http://srp.stanford.edu
> http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol
> 
> Pretty cool stuff. JavaScript implementation available for client side.
> 
> Jim, the article you sent did not cover iterated hashing although you
> mentioned it in your blurb. Did I miss something? Or maybe your own
> conclusion? I'm kind of interested in that part, see. :)
> 
>    Regards, John
> 
> 
> 2011/2/19 Marco M. Morana <marco.m.morana at gmail.com>
> 
>> I think is a good idea to increase the processing cost still maintaining
>> compatibility with old password hashes like bycrypt does. This way you do
>> not need to continuously upgrade algorithms and key lengths such as MD5 to
>> SHA-1 and SHA-2 to keep up with processing speed, you can keep the same
>> algorithm and change the “work” factor of the algorithm to catch up with
>> increased attacker availability of processor performance at reduced cost.
>>
>>
>>
>> I am not sure how bcrypt compares with SHA1 or 2, the article mentions
>> about 100 million times faster (from microseconds (10^-6) to tenth of a
>> second (10^-1) by comparing it with MD5 that is not acceptable by most
>> encryption standards today.
>>
>>
>>
>> The problem of adopting bycrypt for hashing is that blowfish is banned by
>> most business encryption standards (including the FI that I work for) as
>> well as FIPS-140
>>
>>
>>
>> Regards
>>
>>
>>
>> Marco
>>
>>
>>
>>
>>
>>
>>
>> *From:* owasp-leaders-bounces at lists.owasp.org [mailto:
>> owasp-leaders-bounces at lists.owasp.org] *On Behalf Of *Jim Manico
>> *Sent:* Friday, February 18, 2011 5:07 PM
>> *To:* ESAPI-Developers; owasp-leaders at lists.owasp.org
>> *Subject:* [Owasp-leaders] How to store a password
>>
>>
>>
>> I think the convential wisdom to use a SHA-2/salted/iterated hash for
>> password storage is just wrong. Here is a solid article that discuses why.
>>
>> http://codahale.com/how-to-safely-store-a-password/
>>
>> Thoughts?
>>
>> How To Safely Store A Password<http://codahale.com/how-to-safely-store-a-password/>
>>
>> *31 Jan 2010*
>> Why Not {MD5, SHA1, SHA256, SHA512, SHA-3, etc}?
>>
>> These are all *general purpose* hash functions, designed to calculate a
>> digest of huge amounts of data in as short a time as possible. This means
>> that they are fantastic for ensuring the integrity of data and utterly
>> rubbish for storing passwords.
>>
>> A modern server can calculate the MD5 hash of about 330MB every second<http://www.cryptopp.com/benchmarks-amd64.html>.
>> If your users have passwords which are lowercase, alphanumeric, and 6
>> characters long, you can try *every single possible password of that size*
>>  in around *40 seconds*.
>>
>> And that’s without investing anything.
>>
>> If you’re willing to spend about 2,000 USD and a week or two picking up
>> CUDA <http://www.nvidia.com/object/cuda_home.html>, you can put together
>> your own little supercomputer cluster which will let you try around
>> 700,000,000 passwords a second<http://www.win.tue.nl/cccc/sha-1-challenge.html>.
>> And that rate you’ll be cracking those passwords at the rate of more than
>> *one per second.*
>> Salts Will Not Help You
>>
>> It’s important to note that *salts are useless for preventing dictionary
>> attacks or brute force attacks.* You can use huge salts or many salts or
>> hand-harvested, shade-grown, organic Himalayan pink salt<http://en.wikipedia.org/wiki/Himalayan_salt>.
>> It doesn’t affect how fast an attacker can try a candidate password, given
>> the hash and the salt from your database.
>>
>> Salt or no, if you’re using a general-purpose hash function designed for
>> speed you’re well and truly effed.
>> bcrypt Solves These Problems
>>
>> How? Basically, it’s slow as hell. It uses a variant of the Blowfish
>> encryption algorithm’s keying schedule, and introduces a *work factor*,
>> which allows you to determine how expensive the hash function will be.
>> Because of this, bcrypt can keep up with Moore’s law. As computers get
>> faster you can increase the work factor and the hash will get slower.
>>
>> How much slower is bcrypt than, say, MD5? Depends on the work factor.
>> Using a work factor of 12, bcrypt hashes the password yaaain about 0.3
>> seconds on my laptop. MD5, on the other hand, takes less than a
>> microsecond.
>>
>> So we’re talking about *5 or so orders of magnitude*. Instead of cracking
>> a password every 40 seconds, I'd be cracking them every *12 years* or so.
>> Your passwords might not need that kind of security and you might need a
>> faster comparison algorithm, but bcryptallows you to choose your balance
>> of speed and security. Use it.
>>
>>
>>
>> Feedback appreciated,
>> Jim
>>
>> _______________________________________________
>> OWASP-Leaders mailing list
>> OWASP-Leaders at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>>
>>
> 
> 
> 
> 
> _______________________________________________
> Esapi-dev mailing list
> Esapi-dev at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/esapi-dev



More information about the OWASP-Leaders mailing list