You can't use a "random" salt (such as one generated from the rand function) because then you can't calculate the hash later to verify they entered the correct password, unless of course you store that "random" salt in the database, which would defeat the purpose if your database is compromised.
Typically hash's are calculated using something like:
$hash = sha1($password."secretcode".$username); - none of which are random.
If you were to add a random number into that like this:
$rand = rand(1,99);
$hash = sha1($password.$rand);
Now you can't do if($hash1 = $hash2) { loginSuccess(); } because you will never know what random salt was generated for the original hash.
>unless of course you store that "random" salt in the database, which would defeat the purpose if your database is compromised.
Not true, a plain hash can be compromised with a brute force attack. To do this all the entries in the dictionary(used in the attack) must be hashed using the same hash algorithm.
If each password entry is hashed with a random salt(with the salt being kept for password comparison) the attacker must rehash the entire dictionary(not a computationally cheap thing to do) including the random salt, for each and every password.
This doesn't make it impossible to brute force a hash+salt, but makes it a LOT more expensive and time consuming.
At least this is my understanding of the whole point of random salted hash.
this is my understanding too, even if someone breaks into the db and gets the list of salts and passwords, they can't use rainbow tables because of the "random" salts, so finding the plain text passwords becomes computationally too expensive to accomplish.
