> Similar to Linkedin with 6.5m, we have a real-world case study. Except that Linkedin's passwords weren't salted. > When you say "entire password space" you'

> Similar to Linkedin with 6.5m, we have a real-world case study. Except that Linkedin's passwords weren't salted. > When you say "entire password space" you're implying that there's a hard upper limit on the complexity of a user's password 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. > So our expectation is that the easiest 500,000 accounts will be cracked in the first 5.2 seconds by an attacker with a single GPU OK, I concede that point that in this case the salt is not helping so much, at least for users using the 10000 most common passwords. For the few hundred thousand users users whose password lies in a larger key space (but still in the range of bruteforce), the salt still protects them. Getting back to your original point > Modern password cracking has all-but obsoleted both of these reasons [for having a salt] Let's look at a better hash function - bcrypt. In this case hashing passwords is still slow enough (by design - you can slow it down to whatever you want) that rainbow tables would again be useful - to compute the hash of 10000 passwords with a difficulty such that each hash takes 1 cpu-second to compute will take almost 3 hours. Adding salts makes this a per user operation instead of a global one.