One of these days we will shut down the "Salting password hashes is a useful thing to do." meme from 1994.

See: http://codahale.com/how-to-safely-store-a-password/ for details.

> One of these days we will shut down the "Salting password hashes is a useful thing to do."

Uh? Why? It is a useful thing to do. More than that, it is necessary (but not sufficient). There's a reason why all of pbkdf2, bcrypt and scrypt generate salts if you leave them to their own devices.

> See: http://codahale.com/how-to-safely-store-a-password/ for details.

You completely misunderstand the article.

It's implicitly understood by everyone who cares about this topic that salting is intrinsic to KDFs. I.E. by the time you've read through, and understood http://codahale.com/how-to-safely-store-a-password/, you understand why "salting" your password gains you nothing, because rainbow tables are no longer particularly relevant to cracking passwords. And yes, while there is salting inherent to KDFs, that's not the major feature of them, but an assumed implementation detail.

> rainbow tables are no longer particularly relevant to cracking passwords

If you use a common hash with no salt you can bet your britches the attacker will use rainbow tables!

It's also worth pointing out that rainbow tables aren't the only attack you are exposed to if you don't salt your passwords - it also prevents finding collisions, and massively slows down forward hashing attacks.

Negative on that. Not all algorithms produce the salt internally like bcrypt does--programmers must still be careful to supply a sufficiently lengthy random salt as input to PBKDF2, for example. Labeling folks who know this as stuck in the past or ignorant is a mistake.

Of course a salt will not make a single password harder to attack. A salt will however force you to attack passwords "one at a time" by making precomputed hashes useless.

Yes, but you can attack them one at a time at astonishing speed these days.

Which is why you need to not use a hashing algorithm designed to be fast, like SHA, but one designed to be slow, like bcrypt.

There's a reason key derivation functions like PBKDF2 and bcrypt still require a salt as an input.

And there's a reason why high-level libraries like bcrypt handle salt generation and storage internally: if they didn't, people would screw it up. It's amazing how many people blithely use some crazy scheme like

    pwhash = md5("this is my salt" + password)

Progress in password hashing security is primarily progress in making things trivially foolproof and then hectoring people into using them.

Doesn't this crazy scheme protect against brute force when only database is leaked, and "this is my salt" remains secret?

> It obviously won't help if your database is compromised

Good news, everyone: it will!

No, it won't. They can just write a new password + salt in the db and get in as that user.

Well, we need to define the attack if we're going to talk about what will and won't help. Generally when we talk password security, we assume the attack is to discover a large number of users' passwords, not to spoof as one. Additionally, it's more common to get read-only access to the data than it is to be able to execute arbitrary queries against the DB.

But maybe that's not want you want to achieve?