Do I need unique salts with bcrypt in PHP?

Question

I understand that bcrypt is more secure than other methods but still puts you the same situation where you need to salt passwords! If the salt is included in the hash string it's not needed to store it separately in the DB. Everytime I need to create a new hash, meaning a new salt as well, do I have to get all the passwords, extract the salts and check the new one doesn't exist already against my DB passwords? Wouldn't be easier to store directly the salts separately for easy compare? If yes then I don't get:

• the point of storing the salt in plain text
• why bcrypt is more secure than manually use sha256 with salted passwords

Answer 1

I'm actually going to disagree with Curtis Mattoon's answer on a couple of things.

1. When you hash using bcrypt, the salt is stored directly inside the hash, so you don't need to store it separately. I'm not sure what he means by not having to store it at all, because the hash without the salt is completely useless. The salt is needed to verify the password against the hash.

2. I agree on this point. If you are updating one password, you don't need to update them all. In fact, it would be impossible because you (hopefully) don't know the passwords for any other users.

3. You don't need to go through pains to get a unique salt. If that were the case, you could use uniqid, but the problem with that is its output is predictable. Predictability is a bad thing in cryptography. Instead, what you want to do is use a pseudo random salt as close to random as possible (i.e. using /dev/random instead of /dev/urandom). If you have a billion users, you may get one or two that have exactly the same salt, but seriously, is this such a big problem? All it does is doubles someone's chance of brute forcing the password for those two particular passwords out of a billion, and I doubt it's even that high of a chance of a collision occurring. Don't strain yourself over this. Make the salts random, not unique. Using things like last login time or IP address is only going to take away from randomness.

4. As for a comparison between SHA512 and Blowfish, see here SHA512 vs. Blowfish and Bcrypt

Answer 2

This site seems to do a decent job at a brief explanation: http://michaelwright.me/php-password-storage

Quick answer:

1) You don't need to store the salt.

2) You don't need to update all the hashes, if you use a unique salt for each password.

3) I'm no crypto expert, but when you're using a unique salt for each user/password, an attacker would have to use a different set of rainbow tables for EACH user. Using the same salt value across the site means that every user's password would be susceptible to the same hash tables. In the past (for better or worse), I've used a function of the user's last login time and/or last IP as the for their password's salt.

e.g. (pseudocode) $password = hash(hash($_POST['password']) . hash($row['last_login']));

4) I'll defer the "Why is bcrypt better?" question to someone more knowledgeable about such things. This answer may help: How do you use bcrypt for hashing passwords in PHP?