[Owasp-leaders] How to store a password

Dr. Dirk Wetter dirk.wetter at owasp.org
Mon Feb 21 07:10:04 EST 2011

Hi Jim,

the article is not correct IMO.

As far as SHA1 is concerned: yes, it's dead. NIST and others
called SHA1 dead 2 years ago as well as Bruce Schneier. Latter
one because is has a collision weakness:
http://www.schneier.com/blog/archives/2009/06/ever_better_cry.html .
Also note, that even SSL is using SHA1 nowadays.

With CUDA clusters @ EC2 you can probably crack it even cheaper than the
article is referring to/

OTOH you always have to balance security with budget and purpose.
Taking something better than SHA-1 for financial data
seems to me like one should definitely do that. As for a
DB supporting CMS one probably would not need go for this.

SHA2 will be retited at one point that's why SHA-3 is on the way.  SHA2
family provides more bits (sha512 = 512 bits, sha256= 256 bits) whereas
SHA1 is 160 bits. Thus the computing  power needed is much higher (see
Marco's reply). IMHO the
article is wrong as far as SHA2 is concerned.

But the author is IMO also wrong on salts. Of course it slows down the
attack with both precomputed tables and by means of a cuda cluster,
supposed you have different salts for each password.  If you have a lengthy
salt and tables for 512 or even 256 bits of hashes, no storage will
nowadays be able to store rainbow tables for this. And I haven't
heard of reasonable computing times against SHA2 in a CUDA cluster. So
today IMHO a salted SHA2 will still provide good protection.

As for blowfish/bcrypt: It's kind of remarkable as it was started
back in 1993 and it's still alive. It's a encryption algorithm
and no hash function as the SHA family (as the author said). And it was
well  scrutinized during all the years.

But as others said: I wouldn't jump on blowfish as it is not widely
embraced. OTOH it cannot hurt for frameworks to provide this as
an option. But to call SHA2 and even SHA3 dead before it has even
surfaced sounds like rubbish to /me/.



Jim Manico schrieb, Am 02/18/2011 11:07 PM:
>  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 |yaaa|in
> 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 |bcrypt|allows 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

More information about the OWASP-Leaders mailing list