If modern hash algorithms use salts, how are hashed passwords compared to check a correct result?


I’ve used hashing algorithms back in my PHP days using bcrypt, which has a function to compare an entered password on the login form, to the hash stored in the database, but if the salt is random each time, how can the hash be checked?

In: Technology

The salt is random, but static. It is created when the entry is created in the hash table and stored alongside the hash.

When you enter your password, it is hashed along with the stored salt and then compared to the hash entry in the table.

The salt isn’t “random each time” in most systems. A random salt is randomly chosen when the password is set, and stored with the hash. “Entered password” + “stored salt” is the input to the hash function. Salt is prevention against dictionary attacks where evildoers have hashed oodles of common passwords before hand, and are just checking for a hash answer that matches something in their table.

As the other answers said, the salt is stored in the database along with the hash.

At first, this might sound like it defeats the security because anyone with access to the hashes also has the salts.

But the difference is, if I have a database of unsalted hashes, I can generate one hash for each guess I make at a finding a valid password, then compare it against every line in the database. I can also see which users have the same (so likely common) passwords, as their hashes will also be the same.

If I want to brute force a salted database, then for each guess I need to generate a different hash to test against each row, using the appropriate salt, so the process is a lot longer (effectively, on average, it would take about as long to brute force a single user’s salted hash as it would to go through an entire unsalted database).

You store the salt along with the hashed value. The salt doesn’t need to be kept secret — its job is to just reduce dictionary or password reuse based attacks against the hashed passwords.