Secure login authentication for Web applications

Secure login authentication for Web applications

Some days ago I saw a blog post about secure login authentication, but the login authentication algorithm mentioned in this article is a bit complicated and there are still some security flaws. Thinking about the HMAC algorithm I've learned before, I think it's perfectly possible to use the HMAC algorithm to secure login authentication for Web applications.
The so-called security, in fact, is mainly to solve a problem: in the text-based transmission of the HTTP protocol to hide the user input password. Of course, it is also necessary to consider that the user's password cannot be saved in plaintext on the server side.

Perhaps someone will think of one of the simplest idea: on the server side of the password with the hash algorithm (such as MD5, SHA1, SHA256, etc.) to save, after the client also hashed the user password after the server to verify ... The idea is very good, but think carefully, this actually and plaintext password no difference, the two ends of the hash calculation is just the user password changed a look, it is like--the user entered the password after the hash, and then the plaintext transfer to log in the same.

In the end, consider the server side need a more secure password, you can hash the user's password, and in the hash of the time to introduce salt (salt). The salt is randomly generated when the password is saved and is stored in the server's database along with the result of the hash. For example, we can build such a user table:

Field Name Description
Username user name, generally not case sensitive
Salt salt, text, randomly generated
Hashpass encrypted user password, generated by algorithmic hash (salt, password)
It is important to note that the user name can also be counted when calculating the hashpass, but consider the case when the user name is not partitioned, so it can be: HASH (l_case (username), salt, password)

The user logon verification process may be the case if the secure transfer is not considered now:

1. User input user name u and password P, submitted to the server
2. The service side finds the corresponding salt and hashpass in the database through U
3. Use salt to calculate the hash value of the user input password, H = hash (salt, P),
or an HMAC (L_case (U), salt, P)
4. Compare the calculated results H and the Hashpass in the database, if consistent, the validation succeeds
The p that is passed from the client to the server here is a clear text. The next thing to consider is to turn this plaintext into an unrecognized and unbreakable cipher, of course the preferred hash algorithm.

Why not choose the symmetric encryption algorithm such as Des/aes--it is obvious that the client is to calculate the encryption by JS, if the use of DES encryption algorithm, the user password here may serve as two roles, one is key, in this case, requires the service side with the same key to decrypt, Then the key needs to be stored in clear text, the security of the storage password, the other role is encrypted data, but in this way, the key will be intercepted by the plaintext (transmitted by the server, or directly in the JS source file), in the case of a key, des can be directly decrypted, The user's password is exposed. A little further thinking, if the user password first by the server-side algorithm to calculate the hash, and then through DES encryption input to the server it? -in fact, the hash process has been the user password irreversible encryption, and then do a des what is the meaning of it?

Then, relatively secure, the login verification process designed by the HMAC algorithm should look like this:

1. The client sends a message to the server requesting the login, which contains the user name U
2. The server obtains u, retrieves the salt from the database, and produces a random number R, which is returned to the client
3. The client makes the first hash algorithm, obtains the password which needs to authenticate on the server side: H1 = HMAC (salt, P)
or HMAC (L_case (U), salt, P)
4. The client makes a second hash algorithm to get the hash value that needs to be transferred back to the server: H2 = HMAC (hash (R), H1)
5. The client transmits H2 to the server
6. The server retrieves the Hashpass from the database based on u, computes HS = HMAC with the same hash algorithm (hash (R), Hashpass)
7. If the Hashpass and the client compute intermediate data H1 Consistent, the HS is consistent with the client's incoming H2, verifying success
8. R is discarded regardless of the success of the verification. The next logon process is generated by the server to regenerate new random numbers R1 participate in the calculation.
The security guarantee here is:

1. Can be intercepted or calculated, only U, Salt,r and H2, even if the database Hashpass is leaked, it is still impossible to calculate the user password P.
2. The H2 used for verification cannot be reused. R as a temporary random number, only valid during the current login process, so r participates in the result of the calculation H2 cannot be used for the next login.

Http://www.2cto.com/Article/201303/198047.html

Secure login authentication for Web applications