The salt does not matter. Neither does the specific hash; you'd be just as boned using SHA256. All cryptographic hash functions are designed to be fast.

The vulnerability is "not using a password hash construction", of which the best known are bcrypt and PBKDF2.

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.

> huge lookup databases

"Huge" being the key word here.

Try searching for the md5sums of arbitrary 8-character alphanumeric passwords. You won't find many results. 62^8 is a big number.

You can download rainbow tables as torrents.

8-character alphanumeric are the ones that are being offered today, it's only going to go up as GPUs get better and HD space/bandwidth increases.

Covering the whole solution space would be an enormous (as compared to just huge) undertaking. But if you limit yourself to the types of passwords people usually use, you can prune it down quite a bit.

The currently available databases are surprisingly large, even if not in the scale of 62^8. Consider a random pick from decrypt.fr: "phytostrote972". It's far from a random string, but not exactly a trivial one either.

> Covering the whole solution space would be an enormous (as compared to just huge) undertaking

A HD 5870 can churn through MD5s at about 2.8 billion/sec - 62^8 inside 24 hours on a single unremarkable GPU.

I believe that with GPUs it's now faster to calculate possible MD5s on-the-fly than use rainbow tables.

Hence the current advice is to use "alongpassphraseasyourpassword" rather than "L33$Pa55wd"

This is where password management gets ridiculous, because you'll find a lot of registration forms limit the length of your password input to, say, 12 or 16 characters.

Why? Is it not being hashed? I have a (possibly very wrong) inkling that a longer phrase might increase the chance of collision but even so, so many places enforce a strong password but force you to keep it short.

The worst offender is NVidia. They have half-a-dozen different developer logins for different bits of their site - and they all have different rules = your CUDA one must have a symbol but the parralel Nsight one must not etc

I greatly doubt that it is faster to compute on the fly then to use a rainbow table.

I think the record is just under 1Billion hashes/sec on a couple of NVidia Tesla cards linked by SLI.

You need a fairly expensive SAN to pull 1Billion MD5 hashes/second just from the raw disk - nevermind the DB lookup.