Why add "salt" to your password?

Turn from Libuchao ' s blog

Salts (SALT)

In cryptography, this process is called "adding salt" by inserting a specific string at any fixed location in the password, so that the result of the hash is inconsistent with the hash result of the original password.

This is the definition of salt on Wikipedia, but it's hard to understand what salt is, and what it does.

First generation password

Early software systems or Internet applications, when designing user tables in a database, are roughly the same structure:

 mysql> desc user;+----------+--------------+------+-----+---------+-------+| field     | type         | null |  key | default | extra |+----------+--------------+------+-----+---------+------ -+| username | varchar (  | NO   |    )  |         |       | |  password | varchar ( | NO   |     | )         |       |+----------+------ --------+------+-----+---------+-------+

The data is stored in the following form:

Mysql> SELECT * from user;+----------+----------+| UserName | PassWord |+----------+----------+| Lichao | 123 | | Akasuna | 456 |+----------+----------+

The main key field is so two, one is logged in the user name, a corresponding password, and that time the user name is stored in clear text, if you log on when the user name is 123, then the database is 123. This design idea is very simple, but the flaw is also very obvious, once the database leaks, then all user names and passwords will be leaked, the consequences are very serious. See the CSDN detailed 6 million user password leak the whole story.

Second generation password

To circumvent the flaws in the first generation of cryptographic designs, smart people do not store plaintext passwords in the database, instead store encrypted passwords, and typical cryptographic algorithms are MD5 and SHA1, whose data tables are roughly designed like this:

 mysql> desc user;+----------+--------------+------+-----+---------+-------+| field     | type         | null |  key | default | extra |+----------+--------------+------+-----+---------+------ -+| username | varchar (  | NO   |    )  |         |       | |  pwdhash  | char (+)      | NO   |      |         |        |+----------+--------------+------+-----+---------+-------+ 

The data is stored in the following form:

Mysql> SELECT * from user;+----------+----------------------------------+| UserName | Pwdhash |+----------+----------------------------------+| Lichao | 202cb962ac59075b964b07152d234b70 | | Akasuna | 250CF8B51C773F3F8DC8B4BE867A9A02 |+----------+----------------------------------+

hash .

Strictly speaking, this algorithm can not be considered as encryption, because theoretically, it cannot be decrypted. So even if the database is lost, but because the password in the database is ciphertext, it is impossible to judge the user's original password, so the consequences are not too serious.

Third generation password

Originally the second generation of password design method has been very good, as long as you set the password slightly more complex, there is little likelihood of being cracked. But if your password is not complex enough, the likelihood of being cracked is still relatively large.

Good people collect common passwords, then perform MD5 or SHA1 on them, then make a very large data dictionary, and then compare the passwords in the leaked database, if your original password is unfortunately included in the data dictionary, It won't take long before you can match your original password. This data dictionary is easy to collect, the CSDN leaked 600w password, is very good raw material.

As a result, the third generation of password design method was born, the user table more than one field:

mysql> desc user;+----------+-------------+------+-----+---------+-------+| field     | Type        | Null | Key  | default | extra |+----------+-------------+------+-----+---------+-------+|  Username | varchar ( | NO   |     |  )        |       | |  salt     | char (    | no   |)      |         |        | |  pwdhash  | char (+)     | NO   |      |         |        |+----------+-------------+------+-----+---------+-------+ 

 mysql> select * from user;+----------+----------------------------+--------------- -------------------+| username | salt                        | PwdHash                            |+----------+----------------------------+-------------------------------- --+| lichao   | 1ck12b13k1jmjxrg1h0129h2lj |  6c22ef52be70e11b6f3bcf0f672c96ce | |  akasuna  | 1h029kh2lj11jmjxrg13k1c12b | 7128f587d88d6686974d6ef57c193628 | +----------+----------------------------+----------------------------------+

Salt can be any letter, number, or a combination of letters or numbers, but must be randomly generated, each user's Salt is not the same, when users register, the database is not stored in plaintext password, nor is it simple to hash the plaintext password, but MD5 (plaintext password + Salt), that is to say:

MD5 (' 123 ' + ' 1ck12b13k1jmjxrg1h0129h2lj ') = ' 6c22ef52be70e11b6f3bcf0f672c96ce ' MD5 (' 456 ' + ') 1h029kh2lj11jmjxrg13k1c12b ') = ' 7128f587d88d6686974d6ef57c193628 '

When the user logs in, the same algorithm is used to verify the line.

Because of the salt, even if the database is compromised, but because the password is added Salt after the hash, bad people's data dictionary has not been directly matched, plaintext password is cracked out of the probability of greatly reduced.

Is it absolutely safe to add Salt? Indifferent No! The bad guys can still get their passwords in the data dictionary, plus we leak the Salt in the database, hash it, and then match it. But because our Salt is randomly generated, if our User data table has 30w data, the data dictionary has 600w data, bad people if want to completely overwrite the bad, they add Salt and then hash the data dictionary data volume should be 300000* 6000000 = 180000 0000000, 1.8 trillion ah, the cost of doing bad things is too high. But if you just want to hack a user's password, just add a Salt to the 600w data, and then hash matches. The visible Salt, while greatly improving the safety factor, is not absolutely safe.

The actual project, Salt does not have to be added in the front or the last surface, can also be inserted in the middle, you can also insert, can also be reversed, the program design can be flexibly adjusted, can make the difficulty of the crack index-level growth.

PS, the text of the so-called tertiary code of the name, is my own YY.

Why add "salt" to your password?