Salt passwords
This note is intended to shed light on the use of salt when hashing a password. If you look in the comments on this topic habrahabr.ru/post/145642 , then there is a suspicion that some people misunderstand the purpose of salt. I will try to show by examples what this mechanism is used for. I ask everyone interested under cat.
Imagine a simple authorization. A user gets a bunch of username / password values, we get a password hash and compare this bunch with the data stored in the database. For simplicity, we will use MD5 and PHP code examples.
In this case, if the user has the qwerty password , we will get the following hash: d8578edf8458ce06fbc5bb76a58c5ca4 . If an attacker gains access to our database, he can take advantage of ready-made services ( http://wordd.org/D8578EDF8458CE06FBC5BB76A58C5CA4 ) in which he already has values that give this hash, or he can remove it himself.
To protect against already prepared hash tables with values, you can use a static salt:
Now with the same qwerty password, we get a completely different hash bdadb0330124cda0e8499c9cd118f7bd . Ready-made tables will no longer help the attacker, he will have to use brute force. This is where the minus of static salt lies: an attacker will be able to generate his hash table with a static salt and get the values of most passwords from the database. To eliminate this minus, a unique salt is used for each hash:
Those. now in addition to the login / password hash, the database will need to store the value of the generated salt for each user. Let's analyze an example: we have two users: user1 and user2. Both use the qwerty password . But in the first, zxcv salt was generated, and in the second asdf . As a result, users with the same password will have different hashes: 1d8f3272b013387bbebcbedb4758586d and a192862aa3bf46dffb57b12bdcc4c199What this gives: now it will not be possible to generate one hash table; to find the value of the hash with the dynamic salt, it will have to be regenerated. All this is aimed at increasing the time of selecting values in the event of a "drain" of the database, using "good" hashing algorithms, it can already take a significant amount of time to select at least a couple of passwords. It is important to understand that the generated salt protects not one single user, but all together from the mass brutus. That's all, I want to remind you that use cryptographic hash algorithms SHA1, SHA512. The MD5 used above is not recommended for use, as recognized obsolete.
Kolonist summarized well in his comment habrahabr.ru/post/145648/#comment_4894759 (for which he thanks a lot and plus):
Once again.
1. No salt - use ready-made rainbow tables.
2. There is one salt on all - we generate one rainbow table and “break” all users on it.
3. There is a separate salt for each user - separately brute force for each user.
Imagine a simple authorization. A user gets a bunch of username / password values, we get a password hash and compare this bunch with the data stored in the database. For simplicity, we will use MD5 and PHP code examples.
$password = md5($password);
In this case, if the user has the qwerty password , we will get the following hash: d8578edf8458ce06fbc5bb76a58c5ca4 . If an attacker gains access to our database, he can take advantage of ready-made services ( http://wordd.org/D8578EDF8458CE06FBC5BB76A58C5CA4 ) in which he already has values that give this hash, or he can remove it himself.
To protect against already prepared hash tables with values, you can use a static salt:
$password = md5($password . "MyUniqueSault");
Now with the same qwerty password, we get a completely different hash bdadb0330124cda0e8499c9cd118f7bd . Ready-made tables will no longer help the attacker, he will have to use brute force. This is where the minus of static salt lies: an attacker will be able to generate his hash table with a static salt and get the values of most passwords from the database. To eliminate this minus, a unique salt is used for each hash:
$sault = GenerateRandomString();
$password = md5($password . $sault);
Those. now in addition to the login / password hash, the database will need to store the value of the generated salt for each user. Let's analyze an example: we have two users: user1 and user2. Both use the qwerty password . But in the first, zxcv salt was generated, and in the second asdf . As a result, users with the same password will have different hashes: 1d8f3272b013387bbebcbedb4758586d and a192862aa3bf46dffb57b12bdcc4c199What this gives: now it will not be possible to generate one hash table; to find the value of the hash with the dynamic salt, it will have to be regenerated. All this is aimed at increasing the time of selecting values in the event of a "drain" of the database, using "good" hashing algorithms, it can already take a significant amount of time to select at least a couple of passwords. It is important to understand that the generated salt protects not one single user, but all together from the mass brutus. That's all, I want to remind you that use cryptographic hash algorithms SHA1, SHA512. The MD5 used above is not recommended for use, as recognized obsolete.
Kolonist summarized well in his comment habrahabr.ru/post/145648/#comment_4894759 (for which he thanks a lot and plus):
Once again.
1. No salt - use ready-made rainbow tables.
2. There is one salt on all - we generate one rainbow table and “break” all users on it.
3. There is a separate salt for each user - separately brute force for each user.