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.

  • 2
    You'll need little programming knowledge for this. You should use standard password crackers (hashcat-ocl and john-the-ripper) with a good wordlist Oct 12, 2013 at 20:05
  • 4
    Name of company so we know to stay away from them?
    – user10211
    Oct 13, 2013 at 1:33
  • The number of hashes calculated by oclHashcat 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. Oct 15, 2013 at 8:08

3 Answers 3


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


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.

  • 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, 2013 at 17:47

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. Oct 14, 2013 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, 2013 at 15:24
  • But note that scrypt is vulnerable to cache-timing attacks due to secret-dependent memory access patterns.
    – nealmcb
    Aug 10, 2016 at 16:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .