Secure login authentication for WEB Applications

I saw a blog post about secure login authentication a few days ago. However, the logon authentication algorithm mentioned in this article is a bit complicated and still has some security defects. I think we can use the HMAC algorithm to perform secure logon authentication for WEB applications.

The so-called security is actually mainly to solve the problem: hiding the password entered by the user under the HTTP protocol based on plaintext transmission. Of course, you also need to consider that the user password cannot be stored in plain text on the server.

Someone may think of the simplest idea: encrypt the password on the server and save it with the HASH algorithm (such as MD5, SHA1, and SHA256, the user password is also hashed on the client and then uploaded to the server for verification ...... The idea is good, but think about it carefully. This is actually no different from the plain text password. The HASH computing at both ends only changes the user password, it is like-the user enters the HASH password and then transmits it in plaintext for logon.

To put it bluntly, considering that the server needs to save the password securely, You can HASH the user password and introduce SALT (SALT) during HASH ). SALT is randomly generated when the password is saved and stored in the database of the server along with the HASH result. For example, we can create a user table as follows:

Field name	Description
Username	Username, generally case insensitive
Salt	Salt, text, random generation
Hashpass	The encrypted user password is generated using the algorithm HASH (salt, password ).

Note that the user name can also be included in hashpass calculation, but the username is case-insensitive, so it can be: HASH (L_CASE (username ), salt, password)

If secure transmission is not considered, the user login verification process may be as follows:

1. 1. Enter the user name U and password P and submit it to the server.
2. 2. The server finds the corresponding salt and hashpass in the database through U.
3. 3. Use salt to calculate the hash value of the password entered by the user, H = HASH (salt, P ),
   Or HMAC (L_CASE (U), salt, P)
4. 4. Compare the calculation result H with the hashpass obtained in the database. If they are consistent, the verification is successful.

Here, the P transmitted from the client to the server is a plaintext. Next, we should consider converting this plaintext into an unidentifiable or uncracked ciphertext. Of course, the HASH algorithm is preferred.

Why not choose symmetric encryption algorithms such as DES/AES? Obviously, the client uses JS to calculate encryption. If the DES encryption algorithm is used, the user password may act as a Key here. In this case, the server must use the same Key for decryption, and the Key must be saved in plaintext, this compromises the security of passwords. The other role is encrypted data. However, as a result, the Key becomes the plaintext that can be intercepted (transmitted by the server in plaintext, or directly written in the JS source file). In the case of a Key, DES can be directly decrypted, and the user password is exposed. Let's take a deeper look. What if we calculate the HASH of the user's password Based on the server algorithm and then input it to the server through DES encryption? -- In fact, the user password has been irretrievably encrypted in the HASH process. What is the significance of performing DES again?

Therefore, it is relatively secure. The login verification process designed based on the HMAC algorithm should be as follows:

1. 1. The client sends a message to the server requesting logon. The message contains the user name U.
2. 2. The server retrieves the salt from the database and generates a random number R, which is returned to the client together.
3. 3. The client performs the first HASH algorithm to obtain the password to be verified on the server: H1 = HMAC (salt, P)
   Or HMAC (L_CASE (U), salt, P)
4. 4. The client performs the second HASH algorithm to obtain the HASH value to be transferred back to the server: H2 = HMAC (HASH (r), H1)
5. 5. The client delivers H2 to the server.
6. 6. The server retrieves hashpass from the Database Based on U and uses the same HASH algorithm to calculate HS = HMAC (HASH (R), hashpass)
7. 7. If hashpass and the client calculate the same intermediate data H1, the HS is consistent with the H2 passed in by the client, and the verification is successful.
8. 8. R is discarded regardless of whether the verification is successful or not. During the next login process, the server generates a new random number R1.

The security guarantee here is:

1. 1. Only U, salt, R, and H2 can be intercepted or computed. Even if the hashpass of the database is leaked, it is still impossible to calculate the User Password P.
2. 2. H2 used for verification cannot be reused. R, as a temporary random number, is only valid during the current logon process. Therefore, H2, which participates in the calculation result, cannot be used for the next logon.