> In the real-world, at scale the only relevant metric to his cost is the entropy of the password, which iterative hashing doesn't magically increase. > If you

> In the real-world, at scale the only relevant metric to his cost is the entropy of the password, which iterative hashing doesn't magically increase. > If you find it cost-effective to slap a `for (i = 0; i < 10^12; i++)` loop around your hash, you should assume it's cost-effective for your attacker as well. If your work factor is higher, it takes much longer to brute force a password. On my laptop, bcrypt with work factors 13 and 14 take ~650ms and ~1100ms, respectively. In comparison, SHA256 takes 0.110ms. A database of passwords hashed with SHA256 will take days, maybe weeks to recover most of the passwords through brute force. With bcrypt, it would take months or years. This article[1] has some numbers (although they're a bit outdated now): > 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. [1]: https://codahale.com/how-to-safely-store-a-password/ https://codahale.com/how-to-safely-store-a-password/