Why should password add some "salt"
Salt (Salt)
In cryptography, it refers to a specific string by inserting the password any fixed position, so that the result of the hash and the hash result using the original password does not match, a process referred to as "salt."
This sentence is above Wikipedia definition of Salt, but this sentence alone is difficult to understand what Salt, and what role it actually plays.
The first generation of password
Early systems or Internet application software, database tables, when the user design, such a structure is substantially:
mysql> desc User; +----------+--------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +----------+--------------+------+-----+---------+-------+ | UserName | varchar(50) | NO | | | | | PassWord | varchar(150) | NO | | | | +----------+--------------+------+-----+---------+-------+
Forms of data storage are as follows:
mysql> select * from User; +----------+----------+ | UserName | PassWord | +----------+----------+ | lichao | 123 | | akasuna | 456 | +----------+----------+
The main key field is so two, one is the user name of the landing, a corresponding password and user name at that time is stored in clear text, if you login user name is 123, so 123 is stored in the database . This design idea is very simple, but also very obvious flaws, once the database compromised, then all user names and passwords are compromised, the consequences are very serious. See "CSDN 6 million password leak explain the whole story" .
The second generation password
In order to avoid the defect of the first generation design password, smart people in the database are not stored in clear text password, the encrypted password is stored in turn, typically the encryption algorithm is MD5 and SHAl, its data tables is designed such that substantially:
mysql> desc User; +----------+--------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +----------+--------------+------+-----+---------+-------+ | UserName | varchar(50) | NO | | | | | PwdHash | char(32) | NO | | | | +----------+--------------+------+-----+---------+-------+
Forms of data storage are as follows:
mysql> select * from User; +----------+----------------------------------+ | UserName | PwdHash | +----------+----------------------------------+ | lichao | 202cb962ac59075b964b07152d234b70 | | akasuna | 250cf8b51c773f3f8dc8b4be867a9a02 | +----------+----------------------------------+
If you set a password 123, then stored in the database is 202cb962ac59075b964b07152d234b70 or 40bd001563085fc35165329ea1ff5c5ecbdbbeef. When the user logs in, the user will enter the password for the implementation of MD5 (or SHA1) database on the line and then compared to determine the identity of the user is legitimate, this encryption algorithm called a hash.
Strictly speaking, this algorithm can not be encrypted, because in theory, it can not be decrypted. So even if the database is lost, but because database passwords are encrypted and can not determine the user's original password, so the consequences are not too serious.
The third generation of the password
The second-generation design of the original password has been very good, as long as you set the password complexity little possibility that it barely cracked. But if your password was not complicated enough, the possibility to break out of the still relatively large.
Nosy collect commonly used passwords, and then perform MD5 or SHA1 for them, and then made a very large amount of data to the data dictionary, and then leaked the database password on the line contrast, if your original password unfortunately is included in this data dictionary, so it would not take long to put out your original password matches. The data dictionary is easy to collect, CSDN leaked passwords that 600w, is a good raw material.
Thus, the design of the third generation born password, the user table in more than one field:
mysql> desc User; +----------+-------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +----------+-------------+------+-----+---------+-------+ | UserName | varchar(50) | NO | | | | | Salt | char(50) | NO | | | | | PwdHash | char(32) | NO | | | | +----------+-------------+------+-----+---------+-------+
Forms of data storage are as follows:
mysql> select * from User; +----------+----------------------------+----------------------------------+ | UserName | Salt | PwdHash | +----------+----------------------------+----------------------------------+ | lichao | 1ck12b13k1jmjxrg1h0129h2lj | 6c22ef52be70e11b6f3bcf0f672c96ce | | akasuna | 1h029kh2lj11jmjxrg13k1c12b | 7128f587d88d6686974d6ef57c193628 | +----------+----------------------------+----------------------------------+
Salt can be any letters, numbers, or a combination of letters or numbers, but it must be randomly generated, each user's Salt are not the same, the user registration, the database is not stored in clear text password, nor is it simple plaintext password hashes, but MD5 (plain text password + Salt), that is to say:
The MD5 ( '123' + '1ck12b13k1jmjxrg1h0129h2lj') = '6c22ef52be70e11b6f3bcf0f672c96ce' the MD5 ( '456' + '1h029kh2lj11jmjxrg13k1c12b') = '7128f587d88d6686974d6ef57c193628'
When users log in, the same algorithm on the line to verify this.
Due to the addition of Salt, even if the leaked database, but because of password hashes are added after the Salt, bad people have not directly match the data dictionary, the probability of the plaintext password is cracked out is greatly reduced.
Salt is not added after the absolute safety of it? Do not take it lightly! They are bad people still can password data dictionary, coupled with our leaked database Salt, then the hash, then match. However, due to our Salt is randomly generated, if there are pieces of data we 30w user data tables, data dictionary have 600w of data, bad people bad if you want full coverage, they add data and then hash Salt the amount of data dictionary should be 300,000 * 6,000,000 = 1.8 trillion, 1.8 trillion ah, cost too high for it to do bad things. But if you just want to crack a user's password, just add it to Salt 600w of data, then the hash match. Visible Salt although greatly improving the safety factor, but it is not absolutely safe.
The actual project, Salt does not have to add in the front or back, can also be inserted in the middle Well, can also be inserted separately, it can also reverse, program design can be flexibly adjusted, can make exponentially more difficult to crack.
PS, the text called first, second and third generation of the password call, of my own YY.
Article from: https://libuchao.com/2013/07/05/password-salt