The idea of the salt, or least one of the ideas, was to make a mass attack harder.
Suppose all passwords were hashed according to the same key, i.e., there is only ONE salt (which would be equivalent, effectively, to none at all). Now suppose you, wearing your hacker hat, try to do a dictionary attack, or any other similar systematic attack.
Now suppose also that you got a copy of the entire password file (which was NOT kept secret at all in earlier Unix systems, for example).
Here’s the hard, inefficient way to go: Start with the first hashed password in the file, and try to crack it. Try “aardvark”. Nope? Try “barnabas”. Nope? Try “charlie”. Nope? Eventually, you might go on to try the second password in the file.
Here’s the efficient mass attack method: This is what the salt is meant to thwart: Try “aadrvark”. Hash it up once, then compare that to every hashed password in the file, and see if you get any hit. Then try “barnabas”. Hash it up once, then compare that to every hashed password in the file and see if you get any hit. Then try “charlie”. Hash it up once, then compare that to every hashed password in the file and see if you get any hit.
Thus, for the effort of hashing up every prospective password once, you get to attack all the passwords in the file. In any user has chosen “charlie” as his password, you will find it.
Comes now the salt: Suppose, for example, that it’s a 24-bit salt. That means every password that a user could choose can get hashed in any one of 2[sup]24[/sup] ways, depending on which salt was randomly chosen.
So your hacking algorithm could work on the first password in the file, and hash up a bunch of prospective passwords according to the salt there, looking for prospective hits. But for each test password you hashed up, you could not then compare that hash with all the other passwords in the file to look for hits there. The differing salts in every password record prevented that. You had to do all the work all over again for each record in the file.