Hashing passwords with a salt - why use different salt for everyone?

Question

Given a database where we have usernames and passwords, we want to secure users' passwords by hashing them. We should not use only username and passwords in this hash, as someone having data from other sites that uses the same hashing function can come to the same results and thus know our passwords. If we try hashing the passwords by themselves it would be easy to bruteforce the entire database and guess all the passwords. In normal applications, passwords are hashed with a random salt that is stored along with them to prevent them from being bruteforced easily.

However, we could just use username, password and the same salt for every record in the database. This option would save one data field for each record, while the combination of username and password would be unique for our entire database. Is such a solution just as safe as the traditional password hashing scheme, or are there some security drawbacks to them I am not aware of?

Answer 1

Let's try to avoid random per-password salts. If the only requirement for salt is to be unique, which is the case for good password hashing schemes, you'll need:

• $globalSalt$ is a secret random 32-byte string.
• $userId_n$ is a unique user identifier.

You can use, for example, $HMAC$-$SHA256(globalSalt, userId_i)$ to generate salt for each user $i$. Or, with PBKDF2 or scrypt, you can just concatenate the values of $globalSalt$ and $userId_i$.

This scheme achieves uniqueness for salt only when you don't allow users to change their passwords. If you do, salt will be unique per user, not per password, so if someone changes their password, their salt will stay the same. In which case, if there are database leaks at, say, three points in time, given that the salt is unique per user, not per password, the attacker gets some information about passwords (e.g. if the user changed their password to the same value.)

To make salt unique per password, you also have to include some counter of password changes, which you have to update and store, and concatenate with $userId$. Storing this counter per-user defeats the original intention, so you can have a single global counter, making sure it never repeats, in which case you can also drop $userId$ and just use this counter along with $globalSalt$.

If $globalSalt$ is leaked, the only advantage the attacker gets is that he will be able to precompute future hashes for current and future $userId$s, which doesn't seem very useful.

We avoided generating and storing random salts by building a more complex and less secure system. Thus, it's much simpler and more secure, as others said, to use random salts instead of bothering with implementing your own scheme.

Answer 2

Let's play the devil's advocate for a moment, and assume the attacker can reasonably guess that a shared salt is used, and the attacker can create an account on the system:

1. The attacker creates an account, and supplies a known-by-him password for this account.
2. The attacker finds his own password hash in the stolen data. He concentrates on brute-forcing this hash. He already knows the password, and focuses on the salt and composition. Assuming the hash isn't too CPU intensive, he will probably succeed with some patience.
3. After successfully brute-forcing his own password hash, the attacker knows the salt for the entire dataset, and can easily attack the rest of the password hashes.

Additionally, if two different users have the same password, then your 'static' salt does not obscure this fact (the hashes would be identical). This could help an attacker to find higher-value hashes to break.

( For edutainment, Ars Technica has a good and quickly read article on how modern password hash attackers operate. )

So a reasonable password storage scheme would never use a static 'salt' for the entire system; it would have a random salt for each password. A random salt per password is known to work, is easy to generate, and uses only negligible space in the database. See the 'salt' tag for more info.

But even more importantly, please don't write your own code for password hashing. Use a established, well tested library which uses a well established computationally expensive hash. If you happen to develop in Ruby, then bcrypt-ruby or Devise for Rails are reasonable choices. For Python, there is Passlib. Whatever your programming language of choice might be, there is probably a well tested, mature, reviewed password hashing library available.