Q:

Another Question About Salting Passwords

I know there are tons of blogs, articles, and questions on SO about salting passwords, but one thing I haven't been able to find an answer to is this:
If I am generating a password hash like this:
$salt = randomString
$password = $_POST['password'] 
hashedPassword = sha1($password.$salt)

And I have a table like this:
Users
user_id | hashedPassword | salt

Why is it so difficult for an attacker to figure this password out? Can't they just use a rainbow table, or brute force to figure out the salt, and then append the salt to every word in a dictionary attack?

A:

Can't they just use a rainbow table,
  or brute force to figure out the salt,

How would that work? But it's a non-issue anyway - 
assume that the attacker knows the salt. Its purpose is not to be secret, that's why you store it right next to the hash.

and then append the salt to every word
  in a dictionary attack?

Sure they can do that, but they have to do it for that particular user. They cannot amortize the effort over all users in the DB, or use a precomputed table of hash->password mappings.
That, and only that is the point of a salt.

A:

They can do that.  The power is that they would therefore need to generate a new rainbow table for each password (or iterate through each dictionary entry for each password).
So the total compute time for a single password is still the same as for a common salt.  But the total compute time for multiple passwords goes up exponentially...
Oh, and it's typically considered good practice to have two salts.  One stored in the database that's unique per password hash, and one stored on the filesystem that's unique for the whole site.  That way if the database is compromised, there's no significant worry as they only have 1/2 the salts used.  Sure, if the filesystem's compromised they could get it all, but if the filesystem's compromised, they can install password sniffers and other nasties...
I hope that helps...

A:

The point of the salt is not to make a single password stronger. It is about preventing the attacker from scaling up, when attacking several passwords. With the salt, the attacker cannot reuse his efforts into attacking another password; he must rehash his dictionary.
Rainbow tables are nothing magical; they are just a special case of a precomputed table, which is akin to a simple dictionary attack with slightly distinct space-time modalities. Building the rainbow table implies more or less going through the complete dictionary. Precomputed tables are a gain for the attacker if he can use them to attack several passwords. If passwords are salted, then precomputed tables, rainbow or not, will not gain him anything.
That being said, a single password is often weak and can be brute-forced, because the average password will fit in the average user brain, and, as such, cannot be very complex. To mitigate that risk, one should use repeated or iterated hashing. A salt does not help here (but it does not harm either). See this answer for details.

