[rpsw]

But salting is also fundamental in bcrypt. Using an function with adjustable work factor doesn't mean salting is not a good idea. Any cryptologic hash people will mention as a best practice will generally have the notion of salting built-in.

[tptacek]

Virtually no-one implements bcrypt themselves. If you use a bcrypt library, you don't need to think about salting. Therefore, when someone says "they're using individually salted passwords", you can usually count on the fact that they're using a crappy password hash, but that they think they're doing something cryptographically sophisticated.

[statictype]

Not really related, but the popular python library for bcrypt kind of does make you have to think about salting. (And it has some other, er, 'curious' design decisions as well)

http://www.mindrot.org/projects/py-bcrypt/

[rpsw]

So does popular ones for .NET, Java, JavaScript.. I haven't seen one where the work factor is explicitly set in the homepage example yet, though.

[astrodust]

When there's a high-speed bcrypt cracker we will have to stop using bcrypt. Until then the cost of cracking bcrypt is too high to make it practical.

SHA1 and MD5 are trivial to crack as there are many OpenCL implementations made specifically to crack salted passwords.

[rpsw]

Well, the point of an adaptable work factor is that you can keep increasing the cost to generate the hash. The aim is for bcrypt is to be able beat Moore's law, not just be a short-term stop gap.