Hate to be pedantic, and I'm sure you already know this, but you do realize that PBKDF2 uses SHA in HMAC mode right? There's nothing inherently slow about that, it's the repeated iterations of hashing.

You could slap MD5 into PBKDF2 with a high iteration count and achieve comparable security. The problem is that devs often use a hash function a single time.

I'm drawing a line between "cryptographic hash functions" and "password hash constructions". One is a "function", the other a "construction".

Password hash constructions do more than simply run the hash function multiple times.

We are, obviously, saying much the same thing.

Again: the key point here is, don't DIY this part of your application.

Fair enough, I suppose I didn't read your original comment closely enough. I appreciate your essays on the topic, but I fear that too many people have, without a full understanding, drawn the conclusion from them that SHA = bad, bcrypt/pbkdf2 = good, without fully realizing that SHA is an integral part of pbkdf2.

Man I'd be thrilled if everyone just thought "SHA=bad, bcrypt=good".

Really? How would you pay your bills then? :)

Dance lessons.

Sure it matters.

If you don't have a reasonable salt then you're vulnerable to time/space tradeoff attacks like rainbow tables/etc.

Also, in case you haven't used it. Scrypt is pretty damn awesome. It's designed to be memory hard, which makes it very hard to crack even with GPUs.