> Except that Linkedin's passwords weren't salted. My point is that salting a fast hash function is like issuing lifevests to the passengers of the Titanic. It

> Except that Linkedin's passwords weren't salted. My point is that salting a fast hash function is like issuing lifevests to the passengers of the Titanic. It sounds better than nothing, but in practice it only just keeps a handful of them from drowning so they can die of hypothermia a few minutes later. > That's why I said "where the password space could be a dictionary attack or a brute force of passwords up to length 10 of letters, digits, and symbols". I don't actually mean the whole key space, just whatever the attacker chooses to target. Sounds like you think you get to decide what the attacker will target first and when he will give up. > Let's look at a better hash function - bcrypt. Agreed, bcrypt is categorically better. But note that bcrypt includes salting as an intrinsic part of its implementation. So it's not something any web programmer could say "I will/will not salt my Bcrypt thusly". As tptacek says, "if you're typing the letters A E S or 'salting your hashes', you're doing it wrong."