Recently, due to the project, I was involved in the password security of login and registration, so I searched online and saw a very hot post on Zhihu. There are those that don’t make sense, and there are those that do.
The overall look down, said meaningless, except for the backend, front directly send text passwords, or use md5, decypt, sha encryption cipher code, such as from the data, is “clear”, as long as the hijacked, even ciphertext, also does not need to crack, bogus requests directly, so it is good to send. In addition, because the front-end code is running on the user’s local browser, what encryption algorithm is visible to the user, obfuscation, hash, encryption is nothing more than to increase this visibility, does not fundamentally solve the problem.
Say meaningful, say more is to protect user privacy, not plaintext transmission on the network, can prevent the same password cross-site use, not background log plaintext record, increase the difficulty of cracking, prevent the gentleman does not prevent the villain and so on, in general, its significance is not authentication.
But there seems to be one thing in agreement. In general, both sides agree that front-end encrypted transport does not make much sense in authentication, but should be solved fundamentally through HTTPS.
I also talk about my implementation ideas here. Let’s assume that regardless of HTTPS or HTTP, data can be hijacked during transmission. So how do we design encrypted transmissions to protect the user’s password data? Or objectively only HTTP, not HTTPS, how to protect the security of the password as much as possible.
The following is the implementation process, divided into login, registration and password change:
1. In the database, we take the user username as the unique key, and use the simplest MD5 (password) to store the password
2. When the user logs in, after the user enters the username, the username is displayed on the front end, and the /user/login-salt interface is requested on the back end. After the interface verifies that the user name exists, it generates a temporary salt, stores it in a table or cache, and sets a short expiration time, and then returns it to the front end.
3. After the user enters the user name and password, the front-end uses MD5 (MD5 (password) + salt) to encrypt the password and sends it to the /user/login login interface of the back-end for login authentication. If the authentication succeeds, the login succeeds. Return the token after login and delete the temporary salt. If the validation fails, a new SALT replacement is generated and returned to the front end, where the user re-enters and re-validates.
4. If the salt times out, skip login validation, regenerate the replacement and send it to the front end.
5. The above guarantees that the password ciphertext sent each time is unique and can only be used once. Even if the password is hijacked, it cannot be logged in again.
6. The preceding steps can basically ensure the security of login authentication, but there is still a problem. That is, although the login is solved, but the registration or password change is inevitable to send clear text, although the registration and password change is much less frequent than the login operation, but it is still a vulnerability. How can we also use ciphertext in these two operations? So I thought of RSA for asymmetric encryption and decryption.
7. When registering and changing the password, the front end applies for a public key from the back end, or reads the password directly through config, encrypts the user’s password using the public key, and sends the password to the back end. The back end decrypts the password using the private key, obtains the plaintext password, and saves it to the database using MD5 (password). In this way, even if the ciphertext is hijacked, it cannot be directly logged in. Moreover, because of the nature of RSA, even if the hijacker has access to the public key and ciphertext, it is almost impossible to calculate the plain text of the password. This ensures the security of the password during registration and modification.
So far, the ciphertext transmission and implementation of user password in insecure network environment are basically completed. Of course, md5 can be used to replace sha, which is more reliable. Passwords can also be stored in the library by using fixed salt+password. These are more detailed optimization, which will not be discussed in this article.