comparing password hashing algorithms - PoC ideas?

Question

OK so I just started working for a security consulting firm and we recommend SHA 256 (with salt) for password hashing because MD5 is too weak. I have read some brilliant answers (the list is too long!!!) on sec.SE about password hashing over last few months and it would be a sin not to try and prove it to my colleagues and seniors that MD5 and SHA are not suitable for password hashing.

I thought it would be good idea to come up with a PoC (demo databases containing passwords hashed with MD5, SHA 256 and bcrypt and attempting to measure the time taken to generate the hash) accompanied by some standard references.The points that I am willing to make are:

Using SHA 256 over MD5 for password hashing does not improve security .A Password hashing algorithm (bcrypt, PBKDF2) would be a much better choice for storing passwords, of course with unique salts.
Some standard references to support these views. The references are important to support the views.

p.s. I have programming experience but I am a novice when it comes to hardware based password cracking. It's not a "give me teh code" question; I am only asking for ideas and suggestions to make this a better PoC.

You'll need little programming knowledge for this. You should use standard password crackers (hashcat-ocl and john-the-ripper) with a good [wordlist](http://www.openwall.com/wordlists) — CodesInChaos, Oct 12 '13 at 20:05
The number of hashes calculated by [oclHashcat](http://hashcat.net/oclhashcat-lite/#performance) with common hardware are very convincing. For plain SHA-256 this is more than 1 Giga hashes per second, compared with an english dictionary containing about 150000 words... well that makes a fraction of a millisecond. — martinstoeckli, Oct 15 '13 at 08:08

Stephen Touset · Answer 1 · 2013-10-14T20:21:02.220

4

Take a list of 1,000 passwords: some trivial (password, cat), some pattern-based (mY$p455w0rd), some random (s%Xn3,0a9aN), and hash them three different ways: MD5 with salt, SHA-256 with salt, and bcrypt.

Use hashcat on the results.

edited Oct 14 '13 at 20:21

answered Oct 12 '13 at 19:30

Stephen Touset

5,736
1
23
38

Thanks for mentioning hashcat..can you point me to some standard documentation on the same topic..i have understood the practical demonstration part – Shurmajee Oct 14 '13 at 17:47

score 3 · Answer 2 · answered Oct 14 '13 at 12:41

You said you work in a security company, but at the same time, you say that they are not convinced that SHA-256 is not suitable for passwords. So, I'm not sure how is your colleagues knowledge, but I'd add some graphics explaining how the hashing works for SHA-256 and how it works for scrypt. Perhaps a good starting point is the Security Now episode about memory hard problems, which explains how scrypt works and why it's better for passwords.

Side note: some time ago, I did a similar presentation to some developers at a company. I've taken the passwords from their users and ran hashcat against them, while explaining that SHA-256 was not really suitable and that scrypt would be a better option. While I was talking, the passwords were rolling in the background. Suffice to say, at the end of the half an hour presentation, they were pretty convinced that SHA-256 was not good enough. Sometimes, a practical demonstration is better than PowerPoint with numbers ;-)

A practical demonstration can be convincing, but be sure to get official approval first. And make absolutely sure that you don't reveal any of the cracked passwords. — Gilles 'SO- stop being evil', Oct 14 '13 at 21:29
@Gilles Can you point me to some standard documentation which i may use as a proof along with the demo — Shurmajee, Oct 15 '13 at 15:24
But note that scrypt is vulnerable to cache-timing attacks due to secret-dependent memory access patterns. — nealmcb, Aug 10 '16 at 16:37

score 3 · Accepted Answer · edited Mar 17 '17 at 13:14

If your colleagues are not sufficiently awed by thorough explanations or by published benchmarks, and really need a Stamp of Approval by either "actual researchers" (whatever this means) or, even worse, some governmental body, then show them:

The ongoing Password Hashing Competition, who try to find better functions beyond the current bcrypt / PBKDF2 / scrypt triad.
NIST Special Publication 800-132, which is as official as you can get, and explains reasonably well why you need something like PBKDF2.

The tricky point, of course, is to make them aware of what they should already know, without making them feel too much that, well, they really should already know it, with being a security consulting firm and all that. Exposing people to their own incompetence may occasionally trigger a salutary reflex of humility and a will to learn; however, it often induces aggressive reactions which will be counterproductive -- namely, they won't stop using poor password hashing, but they will fire you for your impudence.

comparing password hashing algorithms - PoC ideas?

3 Answers3