A more robust way to ensure that the password is not obtained under the HTTP protocol

A more robust way to ensure that the password is not obtained under the HTTP protocol

Speaking of the question of how to ensure password security for user login under the http protocol: Xiaobai’s first thought may be that when the user enters the password on the login page to log in, the front page encrypts the password entered by the user, and then uses the encrypted password as The http request parameters are sent to the server via the network. Doing so cannot guarantee the security of the user’s account, because someone with a little knowledge of programming can know your password through the http request you send, Xiaobai said again, my password is encrypted, and what it gets is also encrypted. After the password, it does not know my original password and it cannot log in from the login page.

have you ever thought that sometimes I just know your encrypted ciphertext is enough, I can forge the http request myself and add the ciphertext to the request parameters, the same Can log in to the system. Da Bai has something to say at this time, Da Bai: I can add salt to the password. Well, let’s look at what salting is. To put it simply, the program adds a random number to the original password set by the user to enhance the complexity of the user’s password, and then encrypts the combined password for storage. Every time the user logs in , The front-end first encrypts the user’s input password and transmits it to the back-end, then the back-end obtains the user account to the database to find the user’s salt, and then performs an encryption together with the transmitted plaintext combination and compares it with the password in the database to determine whether Is in line with the user. But ah, you see, you can’t control other people to get the ciphertext through your http request by doing this. After getting the ciphertext, they will still use your identity to log in to the system to operate. Okay, let me tell you the true meaning of salting: the meaning of salting is not to ensure the security of the password transmission on the network, but to prevent the database from being invaded. Because the original password is too simple, it is analyzed by others. , And then know the password. After directly MD5 processing the password, reverse decryption is indeed very difficult, but the flaws can still be found For example: if two or more people have the same password, they will get the same result after being encrypted by md5. A password can be broken by breaking one. If the user can view the database, then he can observe that his own password is the same as that of other people's passwords. Then, other people use the same password as themselves, so they can log in with someone else's identity. So is our previous encryption method invalid for this behavior? In fact, just a little confusion can be prevented, which is called "salting" in encryption terminology. Specifically, other components (generally user-owned and unchanged factors) are added to the original material (user-defined password) to increase the complexity of the system. When this kind of salt is combined with the user password, and then digested, a more concealed digest value can be obtained. Xiaohei said: I understand what you said, let me tell you the final plan: After the user enters the account, the background Ajax sends the user's account to the server, and at this time the server generates a random number verification code for the account. Respond to the front-end login page. After the user enters the password, the front-end page encrypts the password entered by the user, and then combines the encrypted ciphertext and the verification code returned by the server to encrypt again. Then the information is sent to the server, and the verification code of this account is stored in the server session. The server will obtain the user's password and verification code from the database, combine and re-encrypt it with the plaintext sent from the front end for comparison and judgment. Ok, let us analyze why it is safe, because the verification code is one-time, so after you get this request at the network layer, you cannot do a replay attack, because the verification code is incorrect. And when you get it The new verification code, but you don’t know what the previous content [md5(md5(password) + user’s QQ number)] is, so you can’t re-send this request to achieve the purpose of logging in. 32-bit MD5 + 4 digits The verification code is a 36-digit string, you can crack it. It is estimated that you will not be able to crack it when you hang it. As for the server verification, just use the recorded MD5 value (not the recorded ciphertext) and perform the same The result of the calculation is the same as the one submitted, that is, the password is correct. The content of the verification code is issued by the server and is one-time, so the client cannot be forged or reused. The following is a snippet of the source code of the previous webpage of QQ : The login module on the Q web page (full HTTP/GET request). When QQ is logged in,

 function getEncryption(password, uin, vcode, isMd5) {
        var str1 = hexchar2bin(isMd5? password: md5(password));
        var str2 = md5(str1 + uin);
        var str3 = md5(str2 + vcode.toUpperCase());
        return str3
    }

The vernacular is: md5(md5(md5(password) + user's QQ number) + verification code) Now you know how to ensure password security under the http protocol.

Then we are talking about whether we want to save the user's password in the session after the user logs in.

The password modification code written by a colleague in the past found that the user's login password was stored in the session, and then the original password was read directly from the session when it was judged.

Is it safe to store the password in the session? The saving method of the session is relatively safe. Because the information is stored on the server and the cookie method is uncontrollable on the server side, it is always a danger to the leakage of user information, but there are also Many use cookies to store user information, usually using encryption for processing. We often see that many websites set to remember usernames and passwords, using cookies. In terms of feasibility, I do not recommend this. Even Sun company uses transient management when setting the password, private transient String password; does not want the password to be serialized, so we can not save the password in the session for convenience.

Finally, we talk about the nature of encryption: it is actually a confusion of the original content, the purpose is to increase the cost of achieving the goal from the surface results. On the issue of web page submission (in fact, all communications have this problem) password, there are several dimensions to ensure security,

The first is the security of the aspect. The first thing to protect for a submission is the password itself. This can be done from the earliest Base64 to MD5 or SHA, but Base64 is reversible, and the protection of the password itself is very weak, ha The Greek algorithm solves this problem by converting data of different lengths into large numbers of uniform length. In theory, this number corresponds to an infinite number of solutions, but limited to the input of the password, it is actually reversible, so the MD5 from the first confusion It has become a three-time obfuscated SHA. However, with the advancement of modern computer technology, the cost of inverse calculations has been continuously reduced. People have to use larger numbers to increase this difficulty. However, in order to compromise on cost and development, people have to use unified In the CS era, because it is difficult to invade both ends of the CS, the algorithms used by the opposite parties are confidential, and the difficulty of cracking is relatively large. In order to ensure openness, especially js itself is a plaintext algorithm, it actually only It can be said that the anti-gentleman can be a villain, so there is a security control. The only purpose of the control is to hide the encryption algorithm with a binary code. If you don't know the algorithm, it is difficult to crack the ciphertext.

The second dimension is time. If the password is the same and the encryption result will be the same, then it is possible to use the encrypted data to simulate the user login action without using the plaintext, so purely encrypting the password cannot actually solve this The problem is that with the salt value, the result of the same data is still inconsistent under different circumstances, but the salt value needs to be agreed, and the rule will always be found out, but the cost is a little higher, so it is still unsafe, which leads to The issue of communication security. Therefore, https uses asymmetric encryption to protect the security of the data path and make the communication invisible. But there is another thing called Trojan horse, so people continue to make fuss about input, including obfuscating input, that is, soft keyboard. Good controls will not store plaintext in memory. This is very important. The previous VB and Dephi password controls only looked at No, the actual memory is full of plaintext, which is easy to be used by viruses and Trojan horses. Therefore, in general, the most secure bs system now uses controls to protect input, hides its own HASH algorithm, and uses HTTPS to protect communications.