Does it make sense to store the salt of a password with the hash itself?

4

Looking at tables in a database for a certain product, I came across a structure similar to this:

[LocalUsers]
UserId           Integer
PasswordHash     Byte[]
Salt             Byte[]

If an attacker gets this list, is it sufficient for him to apply discovery techniques, such as clean hashes (without salt)?

Supporting Question: How to safely have password hash?

    
asked by anonymous 04.08.2017 / 22:16

1 answer

4

No problem at all. The "salt" function is to avoid collisions of equal passwords or hashes that are the same. Your job is not to establish a secret, it's just to avoid discovering a password by coincidence.

As shown in the linked question and others on the subject it is important that it be random and sufficient to avoid duplicity of interpretation.

The strength of the hash should be sufficient for the case of compromising the password database, do not give this responsibility to salt .

Strength is something general, it is the difficulty of breaking it. For example, there is a new one that is safer than existing ones when that question was answered: link . If there is an attack, salt does not influence anything, so you do not need to protect it, it is used to combat other types of attacks, not to prevent an attacked server from stealing passwords, in this case the hash should be the best possible, that's what's in the answer.

If you do not put it there, it will put you where? In another table? It does not matter for safety. In another database? It does not change anything. On another server? It helps only a little, but it creates a complication for the software.

    
04.08.2017 / 22:54