About Salt-value encryption

The first time I heard about the value of salt encryption, it always feels strange. Because it is always associated with salty, the association of the password is salty.

in fact, the salt mentioned here, simply said, is a set of safe random numbers. it will be added to the password at certain times (usually encrypted password). This makes the password more delicious (from a single simplification to a complication) and more secure.

Let's talk about the current two forms of salt by security threat Analysis:

First, the database leaks

It is well known that the user name and password are stored in the database. However, once the database has been compromised, the user name and password are compromised. An attacker can easily obtain a user name and password for operation. The bigger danger is that there are more and more websites and apps that need to be registered. User names and passwords are often the same. Once a leak has occurred somewhere, the consequences will slowly spread. These hazards can be queried in recent years, the occurrence of some security incidents, such as Sony database leaks, NetEase database leaks, CSDN database leaks.

The common way to solve this problem is to:

1, encrypt the password to store

The advantage is that even if the database is compromised, the attacker will not get the plaintext password and still cannot use the password directly.

But there are drawbacks to this type of storage: Many users are using weak passwords when registering. Attackers can use a variety of weak passwords through a large number of registered users who use the proliferation. When the database ciphertext is obtained, the relevant rainbow table can be acquired according to the known username and password. Then match the password in the database according to the Rainbow table. This allows you to get a user with a weak (anti-theft connection: This article starts from http://www.cnblogs.com/jilodream/) password. At the same time, apps, web and other software due to user experience, and so on, it is not possible to let users set high safety factor password. If more than 8 digits, including case, special characters, the last three times the password can not be the same, the last password is at least three bits different, cannot contain the password dictionary involved in the simple password and so on. For example: ATM, the payment password using a pure 6-digit number, so that there is a 10^6, the attacker can only get a full set of password corresponding to the Rainbow table, you will be able to get all the user's password. This set of rainbow tables can be used by attackers to register users by using a large number of simple passwords. It then finds the user data that the attacker has registered for himself from the retrieved database to get the Rainbow table. So what's the solution? This involves fixing salt-value encryption.

2. Encrypt the password

As mentioned earlier, this salt is a random number. When a user registers a simple password, the system generates a salt that corresponds to the user and is saved to the database.

This way, when the user's password is 888888, the background of the real stored password when 888888 salt after the value.

The procedure is as follows:

(1) Registration, change the password, the front desk will be 888888 encrypted pwd1, incoming backstage

(2) After getting pwd1 in the background, generate a corresponding random number salt. Pwd1 and salt are stitched and encrypted again, generating PWD2

(3) The PWD2 and salt are stored in the database in the background.

(n) After each user enters the user name password, the password is encrypted to generate PWD1 ', into the background.

After the background to get Pwd1 ', according to the user name ID to get the corresponding salt value. When encrypted with the salt value stitching, generate PWD2 '.

Then determine if Pwd2 ' is consistent with the PWD2 in the database.

Here are two points to note:

1, password in the front of the encryption method can be used in different forms

2, the salt value of the stitching does not have to be spliced to the end, can also be placed in the front, inserted in the middle, or even open or reverse stitching.

3, (Anti-theft connection: This article starting from http://www.cnblogs.com/jilodream/)

It doesn't matter if it's a simple password. Because the same password is not stored in the same value in the database. An attacker could not construct a valid rainbow table for cracking.

(ii) Replay attacks

First, leave the front of the cured salt value encryption do not say, we say another way of attack: Replay attack (Replay Attacks) is also called replay attack, replay attack or fresh attack (freshness Attacks).

Here's a simple example: when user A logs in, the front desk sends the encrypted password to the server as a packet. After the service side will be salt and other encryption means, then the security check. But if the packet is intercepted by an attacker. and analyze the structure of the packet (such as which field represents the user name, which represents the ip/session ID), and then make the appropriate changes, once again sent to the server, the service side will still do a regular check, will still be verified through. In other words, regardless of the client, the service side of the encryption method how complex, once the attacker has the ability to intercept and modify the front and back communication packets, then these attacks will not work.

So how to guard against it? Think about replay attacks, the attacker is using a packet (anti-theft connection: This article starting from http://www.cnblogs.com/jilodream/) in the user name password and other parts of the same mechanism.

So we can make him change, how to change it?

The general idea is as follows:

Each time we log in, we can generate a random number (a dynamically generated salt), which is saved in front of the background for each copy.

() when username is entered after password pwd. The front desk encrypts F1 (PWD), and then it is spliced with the dynamically generated salt and then encrypted again.

That is Pwd1=f2 (F1 (PWD) +salt). The front desk then sends this PWD1 to the backstage. (Note that the dynamic salt changes every time, so the pwd1 changes every time)

After getting the data in the background, if you do not use the cured salt value encryption, directly the data in the database in the same way with the server to save the dynamic salt splicing encryption and then contrast.

If there is also a cure salt value encryption, you need to find a way to remove the dynamic salt (ie F2 () using a reversible secret algorithm), and then splicing the cured salt and then again encrypted, and finally compared with the database.

About Salt-value encryption