I know that a good password hashing algorithm should be slow. MD5, SHA256, etc. are fast. So I've been adding multiple iterations of SHA-256 hashing to my web apps (around 50000). Getting the hash of a password takes about 150ms on my machine.

Is there any advantage of bcrypt over this approach?

Note: I know about salts and pepper. Let's not talk about this here.


2 Answers 2


Inserting the salt (yes, it must be talked about), and iterating the function at the same time, is a bit more tricky than what it usually appears. In particular, a hash function such as SHA-256 is not exactly a "random-oracle-like" function; it exhibits some internal structure. Any homemade construct could hit one of those fine details from which deadly weaknesses may emerge.

Making sure that you did it right is difficult, just like building any cryptographic algorithm. That's where bcrypt is better than any homemade construct: bcrypt has been published and in use and presumably inspected for flaws by many people over quite some time. This is basically the only hard measure of security that you can get in cryptography. The generic advice of "do not define your own algorithms" applies here too.


The problem you're facing have been already solved, and yes, you're going in the right direction: http://en.wikipedia.org/wiki/PBKDF2

  • 1
    So is PBKDF2 a standardized way of doing what I'm doing with my own function? Or does it have other advantages? Maybe because of HMAC? (not sure I really understand what HMAC says). Thx! Jul 12, 2011 at 9:29
  • 3
    Yes, it's the standardized way. No, HMAC is different. Jul 12, 2011 at 9:52

You must log in to answer this question.

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