Sorry, I didn't think my last comment needed clarifying any further - I actively use the bcrypt class for password hashing - I said Blowfish originally as I was comparing hashing algorithms.
Most encryption algorithms (including block ciphers) can be used as a hashing algorithm for passwords.
Just encrypt a common known plaintext string and use the password as the encryption key. This is exactly how various hashing schemes like UNIX's crypt() (based on DES) work.
Knowing the plaintext (e.g. a set of NUL bytes) is useless as long as the encryption scheme doesn't have a weakness against known-plaintext attacks [EDIT] that allow you to recover the encryption key somehow.
Yes, and Blowfish (or rather, a variant of it with an expensive key schedule) is used as the main building block of Bcrypt in roughly the way you describe. That doesn't mean that Blowfish is Bcrypt.
I feel like such a pedantic dick for harping on this, but the distinction is worth making.
The "don't use bcrypt" is really just think about it before you choose it. He says in the first sentence "If you're already using bcrypt, relax, you're fine, probably."
The other algorithms he mentioned were "scrypt" (mentioned already by GP) and "pbkdf2"[1]. The algorithms really just lie on a line between "well studied" and "theoretical security" with bcrypt in the middle. With the author dismissing bcrypt because its worse than each of the others in one attribute ignoring that it's better than the other in that attribute. Also ignoring that bcrypt libraries are generally more popular and hence more reviewed.
The real point was not inventing your own salting / hashing algorithm.
This is a million degrees of wrong. With bcrypt, scrypt, and PBKDF2, there is no "adding a salt". It's an inherent part of each algorithm. If you're "building" a salt, you're doing it wrong, period.
> It's trivial to build a lookup table like with md5, it just takes longer.
No, that's not true, because each one is initialized with a completely different public salt. You can't generate lookup tables for it, without covering the entire hash space.
Of course there is. As you said, it's an inherent part of the algorithm. But never put it beyond some people to use a trivial salt (or use the same one for all users)
"because each one is initialized with a completely different public salt"
If they follow the proper procedures, yes, building a lookup table is impossible.
Checking the python libraries they make it really easy to use, but you can provide your own salt if you want (you have to manually call 'gensalt' as well)
[1] http://codahale.com/how-to-safely-store-a-password/ [2] http://www.tarsnap.com/scrypt.html