Storing salt along with hashed passwords on web server?
 

Not specifically related to Linux, but hoping someone can help anyway. I've been doing a bit of light reading on password hashing so I'm a noob, but what is the point of storing the salt used to hash a password right alongside the hashed password in a database like I've read that webservers do? I thought the point was that the attacker doesn't know the salt so bruteforcing or dict-attacking the password from the hash would be that much harder. But if he knows the salt already, doesn't that defeat the point? He's back to just generating or looking up the hash function with that salt for that password...am I making any sense from my newbie perspective?

If you have a password hash then the point would be that you can take that hash and match it against existing lists of hash / plaintext pairs. When you also have a pseudo random salt involved, then that hash is vastly obscenely astonishingly less likely to be able to be found in a dictionary.

number of MD5 strings for "password" = 1

number of MD5 strings for "password4847d9d", "password84d83uj" etc... = oooh loads.

does that make sense?

I think so. So the point of the salt is that it's very unlikely that a pre-computed table of hashes for a given string has already been created for that salt right? That means the attacker would have to manually create a table with all possible hashed passwords+that salt.

But why not store the salts that were used to generate user passwords separately so that even if the file with the hashed passwords is compromised, the attacker still has to do some work to acquire the salts? Not worth the extra effort given how long it will take the attacker to create the hash table/reverse-engineer the password even if he has the salt?

because salt + password = hash, so you need the salt still to know if the hashes match. These things don't make anything impossible, just harder and slower to perform.