[Owasp-leaders] How to store a password

John Wilander john.wilander at owasp.org
Fri Feb 18 19:10:27 EST 2011


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
>
>


-- 
John Wilander, https://twitter.com/johnwilander
Chapter co-leader OWASP Sweden, http://owaspsweden.blogspot.com
<http://owaspsweden.blogspot.com>Co-organizer Global Summit,
http://www.owasp.org/index.php/Summit_2011
<http://www.owasp.org/index.php/Summit_2011>Conf Comm,
http://www.owasp.org/index.php/Global_Conferences_Committee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-leaders/attachments/20110219/dc3fe74a/attachment.html 


More information about the OWASP-Leaders mailing list