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:

1. 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.
2. 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.

Answer 1

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.

Answer 2

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.

Answer 3

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