This article discusses the security issue through the example of Web login, login is not simply express commit and record write, its security is the most important issue.

1. A simple HTML example looks at user information security

Standard HTML syntax supports the use of a tag in a form to create an HTTP submitted attribute. Modern WEB logins commonly use forms like the following:

<form action= "Application/login" method =" POST"> username: <input id="username" name="username" type="text"/> <input id="password" name="password" type="password" /> <button type="submit">Copy the code

When submitting a request, the form will obtain the attribute of name in the input label of the form, and pass it to the background as a parameter in the BODY of the HTTP request for login verification.

For example, if my account is user1 and password is 123456, I will send the following HTTP request to the background when submitting the login (captured by Chrome or FireFox developer tools, you need to enable the Preserve log) :

You can see that even though the password field is a black dot, the machine still intercepts the request in clear text.

2. The user password field is directly exposed during HTTP transmission

During network transmission, user information security may be compromised if a user is detected by sniffing. The following uses Fiddler or Wireshark as an example to show that the captured HTTP packets contain sensitive information

3. Can encryption algorithms ensure password security?

The WEB front-end can use an algorithm to encrypt the password field and submit the password as the CONTENT of the Http request, including symmetric and asymmetric encryption.

Symmetric encryption: The symmetric cryptography technology is used to encrypt and decrypt files using the same key.

Asymmetric encryption: requires two keys, a publickey and a privatekey. The public key and private key are a pair. If the public key is used to encrypt data, only the corresponding private key can be used to decrypt data. If data is encrypted with a private key, it can only be decrypted with the corresponding public key.

3.1 Using symmetric Encryption

Encryption and decryption may seem like a good idea after both front and back end negotiations, such as the front end using a simple string shift + string inversion method (for example, of course it’s not that simple). So, if the old password 123456 is shifted first:

123456 - > 456123Copy the code

Then reverse:

456123 - > 321654Copy the code

So this simple method seems to be able to obfuscate the original password, and easily reverse operation by the background recovery. But this has two drawbacks:

1. Modify the code at the same time for encryption and decryption. 2. Front-end encryption is nothing more than written in JS, but JS has the risk of being directly cracked to identify the encryption method.

3.2 Is HTTPS necessarily secure for asymmetric Encryption?

Asymmetric encryption has the existence of public and private keys, which can be obtained at will, and the private key is the local storage used to decrypt the public key. The mechanism of public and private keys seems to guarantee the transmission of encryption and HTTPS, which is still in use today, is based on this principle. But is HTTPS necessarily secure? HTTP has two possible risks: 1.HTTPS can prevent information from being intercepted during transmission. However, if you think about it carefully, HTTPS is an application-layer protocol and SSL is used to ensure information security at the lower layer. 2. During HTTPS packet transmission, if the client is maliciously induced to install the man-in-the-middle WEB trust certificate, the man-in-the-middle attack in HTTPS will also leak the plaintext password to others.

4. The conclusion is that, whether HTTP or HTTPS, passwords must be transmitted ciphertext

Consider that HTTPS does not guarantee user password information, so we should consider to continue to protect the password above the application layer, that is, write code to control, and do not depend on a specific protocol, it is easy to think of the use of irreversible encryption hash MD5(string), when users register to enter the password, Stores the MD5(password) value, performs MD5(password) on the WEB, and then transmits the password to the background for comparison with the ciphertext in the database. (PS: MD5 function computes the same value for the same string when the number of digits is specified.) The advantages are obvious: 1. Ensure the security of password information inside the user database; 2. During transmission, the user’s ciphertext will not be decrypted. 3. Simple and efficient, not difficult to execute and encode, all kinds of languages provide MD5 support, fast development.

5. That’s great! This will save you money on HTTPS, right?

Back to the example at the beginning: the user enters user1 and password 123456, so the actual HTTP/HTTPS packet sent under any protocol looks like this after MD5 processing:

That’s right. Encrypted login is working. But while we were celebrating password security, we noticed that the money in our account had suddenly disappeared. Why is that? Hackers laugh very happily: because they do not have to get your password in plain text, if directly intercept your password ciphertext, and then send to the server can not log in? Because the database is not the same as the MD5(password) ciphertext? HTTP requests that are forged can be logged in successfully to grab other data or transfer the balance.

What about this? It’s not that hard. There’s a lot of solutions, right? The principle is similar: the server cache generates a random validation field and sends it to the client. When the client logs in, it passes this field to the server for validation.

5.1 Solution 1: Verification Code

MVC scenarios. The controller encapsulates the Model of the data into the View. This connection mode exists in the Session, allowing access to information in the Session. Then we can use some open source captcha generation tools, such as Kaptcha in JAVA, store a captcha value and a captcha generated picture on the server side, encode the picture in Base64 and return it to View, decode Base64 in View and load the picture. The comparison will be performed the next time the user logs in.

5.2 Solution 2: Token

The front and rear ends are separated. The very popular development mode of front and back end separation greatly improves the development efficiency of the project. The responsibilities and division of labor are clear. However, because HTTP is stateless (that is, this request does not know the content of the last request), when the user logs in, according to the user username as the key, random token (such as UUID) is generated as value cached in Redis, and the token is returned to the client. When the client logs in, the validation is completed and the cached record in Redis is deleted. Each time the token is retrieved from the server, it is guaranteed that the HTTP request is sent back from the front end, because the token is deleted and reset after each login, causing the hacker to attempt to replay the account and password data to log in and fail.

In short, even if I get the ciphertext of the account and password, I cannot log in, because if the request does not contain the token token of background authentication, it is an illegal request.

6. It’s not easy! But don’t rejoice too soon, for the data may be tampered with

The password’s encrypted so the hacker can’t see the plain text. With the Token added, the log-in process can no longer be intercepted and replayed. But think about this situation, you are making online payment on some alipay, which requires four fields: account number, password, amount and token. Then you pay 1 yuan for a bag of small raccoon flat noodles with free mail. After the payment of some alipay, you find that 10,000 yuan has been deducted from your account balance. How does that work? Because even if the hacker does not log in, do not operate, still want to do damage: When the request is routed to the hacker side, the packet is intercepted, and then there is no need to log in. Anyway, the account password is correct, and the token is also correct, so it is ok to change the field of the packet, so it is ok to change the money to 10,000, and then send it to the server. As the victim, I somehow step on this hole. But how to solve this? In fact, the principle is similar to the digital signature mechanism in HTTPS.

6.1 What is a Digital Summary?

When we download files, we often see that some download sites also provide a “digital summary” of the downloaded files, so that downloaders can verify whether the downloaded files are complete, or whether they are “identical” with the files on the server. In fact, the number is to use the one-way Hash function will need to encrypt plaintext “abstract” into a series of fixed length (128) of the cipher text, the string of cipher text is also known as digital fingerprint, it has a fixed length, and different plaintext into ciphertext, the result is always different, and its the same content information must be consistent. Therefore, “digital summary” might be more appropriate to be called “digital fingerprint”. “Digital digest” is the fundamental reason HTTPS ensures data integrity and tamper-proof.

6.2 Digital signature — the natural technology

If the sender wants to send a message to the receiver, before sending the message, the sender uses a hash function to generate a message digest from the message text, and then encrypts the digest with its private key. The encrypted digest is sent to the receiver as the “signature” of the message. The receiver with the same hash function as the sender first calculated from the original message received message digest, then use the sender’s public key to decrypt message added a digital signature to, if the two the same, so the receiver can confirm from the sender sends the message and not been omissions and modify!

This is what can be done with a combination of “asymmetric key encryption and decryption” and “digital digests”, known as “digital signatures”. In this process, the process of generating a summary of transmitted data and encrypting it with a private key is the process of generating a “digital signature”, and the encrypted digital summary is a “digital signature”. Therefore, we can get a field checkCode by signing the username+MD5(password)+token mentioned in the previous case on the WEB side and send the checkCode to the server. According to the checkCode sent by the user and the original data signature, the server performs calculation comparison to confirm whether the data is tampered during the process, so as to maintain the integrity of the data.

7. To summarize

Seemingly very simple WEB login, in fact, there are a lot of security risks. These security improvement process is encountered in a real WEB project, the above analysis and evolution is the solution proposed in the inspection of project security, there will be a lot of deficiencies, hope to communicate and discuss together, common progress!

Addendum 1: the JS encryption function has been cracked

Thank you mysgk for pointing out the problem of cracking JS encryption function in integrity check:

If a hacker finds an encryption algorithm by reading the front-end JS source code, does that mean he can construct checkCode that can be decrypted by the server to fool the server?

I think, should also be a lot of websites are also taking the strategy:

Abstract or encrypted JS algorithm does not directly exist in the browser in the form of static files, but let the WEB end to request the Server, the Server can decide according to the random token value to return a corresponding random encryption strategy, in the way of JS code response, in the asynchronous request response, load JS abstract algorithm, This allows the client to load the digital digest policy dynamically, making it impossible to copy.

Note 2: MD5 has hidden problems

Thanks to EtherDream for pointing out that MD5 is outdated and has unsafe issues:

MD5, SHA256 is out of date… Now PBKDF, bcrypt are out of date.

1. This article focuses on the introduction of method ideas. It is not necessary to use MD5 function, but other ways can be used. 2.MD5 has hidden dangers. I didn’t think too much about it before, but THANK you very much for pointing out that it is true.

For MD5 cracking, actually belong to collision. For example, the original text A can generate abstract M through MD5, we do not need to restore M to A, we just need to find the original text B and generate the same abstract M. If the MD5 hash function is MD5(), MD5(A) = M MD5(B) = M any B is the cracking result. B may or may not be equal to A.

If you intercept the MD5 encrypted ciphertext, you can also find a “pseudo-original text” that is not the original password but can be logged in successfully after encryption. As can be seen from CSDN’s blog on MD5 risks, the MD5 function can indeed be “cracked” in reverse, but this “cracked” is only to find a text that has the same result after the MD5 operation, not the plaintext password of the user. But this will be cracked login may indeed need to use a more sophisticated algorithm for encryption, thanks again.

Original: www.cnblogs.com/letcafe

The author | letcafe; Source garden | blog

Recommend 2 original Springboot +Vue projects, with complete video explanation and documentation and source code:

【VueAdmin】 hand to hand teach you to develop SpringBoot+Jwt+Vue back-end separation management system

  • Video tutorial: www.bilibili.com/video/BV1af…
  • Complete development document front end: www.zhuawaba.com/post/18
  • Full development documentation backend: www.zhuawaba.com/post/19

【VueBlog】 Based on SpringBoot+Vue development of the front and back end separation blog project complete teaching

  • Video tutorial: www.bilibili.com/video/BV1af…
  • Full development documentation: www.zhuawaba.com/post/17

If you have any questions, please come to my official account [Java Q&A Society] and ask me