Origin
The system involves authentication requires authentication information stored in the user's common user authentication methods are mainly the way a user name and password, for security reasons, the password entered by the user needs to be saved in cipher text, can be published irreversible hash encryption algorithms, such as SHA256, SHA512, SHA3, etc., for the same code, the same encryption algorithm will produce the same hash value, so that the same application when the plain text password to authenticate the user, the user may input hash encryption algorithm, derived a hash value, hash value, and then uses the previously stored value ciphertext good contrast, if the two values are identical, the password authentication is successful, otherwise the password authentication fails.
Because the password is set by the user, in practice, the complexity of the user password may not be set high, and very different users may use the same password, then the user will be the same as the corresponding ciphertext, so that, when the database stored user passwords compromised, the attacker will be able to easily find the same user password, which also reduces the difficulty to crack the code, and therefore, when the user password is encrypted, the password needs to be considered to cover, even the same password, it should be saved as different ciphertext, even if the user input is a weak password, need to be considered enhanced, thereby increasing the difficulty of the password is compromised, and the encrypted hash value with the use of salt will be able to meet this need .
In fact, here's salt, simply put, is a set of secure random number . In particular, when it is added to the password ( it is generally encrypted passwords )
Common password attack methods are dictionary attacks, brute force, lookup, reverse lookup table, such as rainbow tables.
Common password attack
To dictionary attacks and brute force , the use-by attack caught password attempts, there is no good means to prevent dictionary attacks and brute force attacks, only to find ways to make these two attacks become relatively inefficient number , the same password will produce different hash values allow an attacker for each hash values from scratch to try, making attacks more inefficient.
For table-lookup , reverse lookup table and a rainbow table attack, the attacker would need to prepare in advance the password table contains passwords and password hash value , then batch matching from the table and user password database, so as to achieve the purpose of compromised passwords ; and if we are in the encryption, password attached to each different random values, so each corresponding to a password hash value will be different, so the attacker in the preparation of the password table, you have to want the most basic password and user password database salt value Cartesian product calculated hash value and then, the more salt value, the greater the amount you need to prepare the table, so for the attack, it becomes somewhat more harm than good.
Notes salt
1, the salt value can not be too short ; if the salt value is only a few two or three or even one or two words, the attacker can exhaust all possible salt value; an empirical value on the length of the salt value is at least the length of the encryption and hash functions the return value consistent length.
2, the salt value can not be fixed ; If the system uses a fixed value of the salt, and then the same thing is not the equivalent of salt, the attacker can use a fixed value prepared in advance in the password table salt; Further, the same hash code corresponding value remains the same, the same still can not conceal the fact that the password.
3. Do not use the values can predict in advance as the salt value ; if the salt value can be learned or inferred in advance in advance, an attacker can prepare according to the value of the password table salt to predict in advance, so as to break the difficulty can not add much.
4, each time modifying password hash value is recalculated, to regenerate a new salt value, do not use the salt value corresponding to the last code Because If the user password leak, the value of the corresponding salts also leaked, the user change the password; If still follow the original value of salt, an attacker can still prepare in advance in accordance with the last password table salt value, so that break possibility becomes even higher.
Database leak
As we all know, user names and passwords are stored in a database. But once the leak occurred database, user name and password have been compromised. An attacker can easily obtain a user name and password to operate. More damage, because the site is now need to register, app more and more. User names and passwords are often the same. Once the leak has occurred somewhere, then the consequences will spread slowly. Some security incidents we can query these hazards occur in recent years, such as the Sony database leak, Netease database leak, CSDN database leak and so on.
General solution to this problem is:
1, the password is stored encrypted
The advantage is that, even if the database leak occurs, the attacker will not get a clear text passwords, password still can not use them directly. But this storage there are also disadvantages: weak passwords, many users are used when registering. An attacker can cause a large number of registered users, these users use the spread of the use of a variety of weak passwords. When the database to get the ciphertext, according to known username and password, you can get to the relevant rainbow table. Followed by matching database password based on rainbow tables . In this way the user can be obtained using the weak password. Meanwhile app, web and other software from the user experience and other reasons, it is impossible to allow the user to set high safety factor password . Such as 8 or more, with case, special characters, in the last three password must be different than the last password with at least three different and can not contain a simple password password dictionary involved and so on. For example: such as ATM, micro-channel payment password using pure 6 digits, so there is 106 possible attacker simply takes the full password corresponding to a rainbow table, you can obtain the passwords of all users ^. This rainbow table, an attacker can get by using a large number of simple passwords registered users. Then find the attacker's own registered user data acquired from the database, and then get rainbow table. So how to solve it? This value relates to the fixed encryption salts.
2, encrypted passwords
As previously mentioned, the salt is a random number. When the user registers a single password, the system generates such a Salt, corresponding to the user, saved to the database.
So that when the user's password is 888888 , the background when the real password stored value after 888888 salinization .
Steps are as follows:
(1) Registration, when you modify the password, the front desk after 888888 encryption pwd1 , incoming background
(2) get back pwd1 later, generates a random number corresponding Salt . The pwd1 with salt stitching and re-encrypted to generate pwd2
(3) The background pwd2 and salt together stored in the database.
(4) When each user enters the user name and password, the generated password encryption pwd1 ' after passing background.
(5) get back pwd1 ', in accordance with a user name id get corresponding salt value . Salts with stitching encrypted value generated pwd2 '.
(6) is then determined pwd2 ' in the database pwd2 are the same can.
There are two points to note:
① preceding background password encryption may take different forms
② salt value splicing not necessarily splicing the end, can be placed on the front, is inserted in the middle, or even disassemble reverse stitching.
③ Even a simple password so it does not matter. Because the same code is not the same as the value stored in the database . An attacker can not construct a valid rainbow tables to crack.
Replay attack
Put aside curing salt value is not encrypted, said front, we say that another attack: replay attacks (Replay Attacks) known as a replay attack, a replay attack or fresh attack (Freshness Attacks).
To give a simple example: When a user A to log in, front password will be encrypted in order to packets sent to the form of the server . After the service will end encryption, such as salting, then security check. However, if the packet is intercepted by an attacker. And analyzing the structure of the packet (e.g., which represents the user name field, the representative of which IP / session ID), and then make the appropriate changes, the retransmission to the server, the server will still check routine, still verified by . That means no matter how complex encryption client, server, once the attacker has the ability to intercept and modify packets stations communicating back and forth, then these encryption methods will not work.
So how do you prevent it? Think about replay attack, the attacker uses the same mechanism is part of the package sent each time the user name password.
Then we can make him change, how to change it?
General idea is as follows:
1, each time landing , we can generate a random number (a dynamically generated salt), the salt former backstage keep a journal.
2. When finished entering the username password pwd. Reception will be f1 (pwd) encryption, and splicing dynamically generated with salt, then re-encrypted.
I.e. pwd1 = f2 (f1 (pwd) + salt). After the reception put the pwd1 sent to the background. (Note that due to the dynamic salt every time change, it will change every time pwd1)
3, to get back the data, if the cure is not encrypted salt value used, directly to the data in the database in the same manner as the stored server dynamic salt splice encryption and then to compare.
If the presence of a curing salt value encrypted at the same time, then, need to find ways to weed out the dynamic salt (i.e., F2 () using a reversible algorithm secret), and then re-encrypted splice cured salt Next, the database can be compared with the last
Reference: https://www.cnblogs.com/birdsmaller/p/5377104.html
