Just suggesting you hash a password is pretty poor form as it'll be easy generate a rainbow table for, and likely many already exist. You use a salt to mitigat

Just suggesting you hash a password is pretty poor form as it'll be easy generate a rainbow table for, and likely many already exist. You use a salt to mitigate this but even if you use a salt, it _has_ to be stored somewhere. Once an attacker has it, they'll be able to create rainbow tables with this in mind. You then move to using a different salt for every password so any rainbow table only works for one result but if you use a fast hashing algorithm, attackers will still be-able generate rainbow tables based on those salts. So you pick a slower hashing method but in the future, as computer hardware advances, you'll be in the same situation where it's trivial to brute force some rainbow tables. So you need to keep on top of it and keep updating the stored hashes with something that is non-trivial to brute force, in PHP this gives you these functions: http://php.net/manual/en/ref.password.php http://php.net/manual/en/ref.password.php. In reality though, in the event of a breach, all you're doing is buying time for your users to change their passwords before the relevant rainbow tables are generated, so the next important step is to let your users know their hashed passwords were leaked, you followed best practices, but they should update the passwords wherever they used it.