Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It only takes a minute to sign up.
Sign up to join this community
Can somebody explain how Salts should be stored in the database? How is the process of using Salt?
I've read in a book that the Salt should be stored next to the hash table database. But what happens if the attacker steals both hash table and Salt value? How many Salt value should we use?
How many Salt value should we use?
The idea of salts is to make the password hashes unique, so an attacker can't re-use computations from cracking one password on to another, so you really should use one unique salt per password hash.
But what happens if the attacker steals both hash table and salt value?
The attacker will be able to brute-force the password of all the users in the table. This may allow him to recover some passwords if the passwords were weak and / or if a weak password hashing function was used. After the attacker recovered the passwords he may try to re-use those at other services where the user used a similar / the same username. If two hashes share the same salt and happen to be the same password (e.g. "123456") then an attacker can effectively recover the password for both users by cracking only one of them.
How is the process of using Salt?
Usually you feed your salt into your password hashing function along with the password and the hash which will then tell you whether the password is valid for this hash and salt. The better schemes (such as Argon2) support a so-called modular crypt format, which is an encoding for the password hash which also includes critical parameters and a new (random) salt (base64-encoded) for each password hash. If you can use this format, it's a one-shot solution as you can just ask the tool / backend to generate a new entry (for a given password) and store it right away and when you have a log-in, you fetch this string and pass it to the verification engine and you're done.
Can somebody explain how Salts should be stored in the database?
Somewhere, where you can directly 1-to-1 map each salt to the corresponding password hash. This may be directly with the hash in the same entry, in a different column or even a different table.
Suppose there are two databases $A$ and $B$. $A$ stores a random salt $salt1$ and a bunch of hashes of the form $h(salt1||password)$ for each password $A$ was submitted with. $B$ stores a random salt $salt2$ and another bunch of hashes of the form $h(salt2||password)$ for each password $B$ was submitted with.
Now imagine there is an attacker who steals the contents(e.g. the unique salt and the hashes) of both databases $A$ and $B$ and wants to learn the passwords. What he is going to do is an attack called dictionary attack. For the database $A$, he is going to build a table containing hashes of the form $(h(salt1||guess), guess)$, for every possible guess he makes. After he is done with that, he is going to take each single hash of database A and compare it with the first element in each entry of the hash table he just built. When he hits a match, he has cracked the password, which is simply going to be the second element of the matching entry.
Now the usefulness of salt is clear: the dictionary he just computed is not applicable to an attack to the database $B$, because the two databases use different salts to create their hashes. So he should build a completely new dictionary, using this time $salt2$ during his computations. This is time consuming and makes the life of the attacker more difficult.
Applying the same argument, you can see that if a database uses a new random salt for each hashed password it stores, then the attacker should build a new dictionary for each password he wants to crack. In other words, in the best case, a database should generate a new random salt for every new password it is submitted with and store pairs of $(salt_i,h(salt_i||password_i)$.
