Shulou(Shulou.com)06/01 Report--

In this article, the editor introduces "Web login case analysis" in detail, the content is detailed, the steps are clear, and the details are handled properly. I hope this "Web login case analysis" article can help you solve your doubts.

Text

1. A simple HTML example to look at user information security

Standard HTML syntax supports the use of tags in form forms to create attributes submitted by HTTP. In modern WEB logins, forms like this are common:

Http://localhost:8080/Application/login" method = "POST" > user name: password: login

When submitting a request, the form form will get the attribute that the input tag exists name in 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 my password is 123456, the HTTP request I will send to the backend when I submit login is as follows (Chrome or FireFox developer tool capture, you need to open Preserve log):

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

2. HTTP protocol transmission directly exposes the user password field

In the process of network transmission, sniffing will directly endanger the security of user information. Take Fiddler or Wireshark as an example, it is found that the captured HTTP message contains sensitive information:

3. Can password security be ensured by using encryption algorithms?

The WEB front end can encrypt the password field through some algorithm, and then submit the password as the content of the Http request, including symmetric and asymmetric encryption.

Symmetric encryption: using symmetric cryptographic coding technology, which is characterized by the use of the same key for file encryption and decryption.

Asymmetric encryption: requires two keys, a public key (publickey) and a private key (privatekey). The public key and the private key are a pair. If the data is encrypted with the public key, it can be decrypted only with the corresponding private key; if the data is encrypted with the private key, it can be decrypted only with the corresponding public key.

3.1 use symmetric encryption

Encryption and decryption seems to be a good idea after negotiation between the foreground and the background. for example, the foreground uses a simple method of string shift + string inversion (for example, of course it can't be that simple). So, if the original password 123456 is shifted first:

123456 music-> 456123

Then reverse:

456123 music-> 321654

So such a simple method seems to confuse the original password and easily be restored by the opposite operation in the background. But there are two drawbacks:

The encryption and decryption of the front and rear ends need to be modified at the same time.

The front-end encryption is nothing more than written in JS, but the JS risks being directly cracked to identify the encryption method.

3.2 does asymmetric encryption HTTPS have to be secure?

Asymmetric encryption has the existence of public key and private key, and the public key can be obtained at will. The private key is the local storage used to decrypt the public key. It seems that the mechanism of public and private keys can guarantee the transmission encryption and even the HTTPS which is still in use is based on this principle.

But is HTTPS necessarily safe? There are two possible risks to HTTP:

HTTPS can ensure that the information in the process of transmission will not be intercepted by others, but after careful consideration, HTTPS is an application layer protocol, and the lower layer uses SSL to ensure information security, but ciphertext can also be intercepted on the client side and server side.

During the transmission of HTTPS message, if the client is maliciously guided to install the WEB trust certificate of "man in the middle", then the "man in the middle attack" in HTTPS will also reveal the plaintext password to others.

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

Considering that HTTPS does not necessarily protect users' password information, then we should consider continuing to protect passwords above the application layer, that is, writing code to control them without relying on specific protocols. It is easier to think of using the irreversible encryption hash function MD5 (string). When users register and enter their passwords, they store the value of MD5 (password) and MD5 (password) on the WEB side. The password is then transferred to the background and compared with the ciphertext in the database (the PS:MD5 function operates on the same string with the specified number of digits). The advantages are obvious:

It ensures the security of password information in the user database.

In any case, the user's ciphertext will not be cracked in the process of transmission.

Simple and efficient, implementation and coding are not difficult, a variety of languages provide MD5 support, fast development.

5. That would be great! This can save HTTPS's money, is that true?

Back to the beginning example: the user name entered by the user is user1, and the password is 123456. No matter under what protocol, you can see that the actual HTTP/HTTPS message sent is like this after MD5 processing:

Web login is not as simple as you think.

Yes, the encrypted login worked. But when we celebrated password security, we found that the money in the account was suddenly missing. Why is that? Hackers smiled happily: because they do not have to get your password plaintext, if you directly intercept your password ciphertext, and then send it to the server, you can also log in? Because isn't the same ciphertext in MD5 (password) in the database? If the HTTP request is forged, you can still log in successfully to grab other data or transfer the balance.

What are we going to do? In fact, it is not difficult, there are many solutions? In fact, the principle is similar: the server cache generates a random authentication field and sends it to the client. When the client logs in, it passes this field to the server for verification.

5.1 option 1: CAPTCHA

MVC scene. The controller will encapsulate the Model of the data into the View, a connection that exists in the Session and allows access to information in the Session.

Then we can use some open source CAPTCHA generation tools, such as Kaptcha in JAVA, to store a CAPTCHA value and a CAPTCHA generated picture on the server, encode the picture in Base64, return it to View, decode Base64 in View and load the picture, and compare it the next time the user logs in.

5.2 option 2: token token

The front and rear ends separate the scene. Now the very popular front-end separation development mode has greatly improved the development efficiency of the project. 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's username as key, a random token (such as UUID) is cached in Redis as value, and the token is returned to the client. When the client logs in, the verification will be completed and the cache record in the Redis will be deleted.

Then every time the token that obtains the authentication from the server can ensure that the HTTP request is sent back from the front end, because the token will be deleted and reset after each login, which will lead to the failure of the login when the hacker tries to replay the account password data to log in.

All in all, even if I get the account number and password of the ciphertext can not log in, because if the request does not include the background authentication token token, it is an illegal request.

6. It's not easy! But don't be happy too early, beware of the data being tampered with.

The password is also encrypted, and the hacker can't see the plaintext. With the addition of Token, the landing process can no longer be intercepted and replayed. But think about this situation, when you are making an online payment on a treasure, you need account number, password, amount, and token to operate, and then when you pay, you pay 1 yuan to buy a bag of free raccoon crisp noodles. After the settlement of a treasure, you find that your account balance has been deducted by 10, 000 yuan. What's going on here?

Because even if the hacker does not log in or operate, he still has to do damage: when the request is routed to the hacker's side, the data 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 change the field of the data packet and destroy it, so change the money to 10, 000, and then pass it to the server. As a victim, you stepped on this hole inexplicably. But how to solve this? In fact, the principle is similar to the digital signature mechanism in HTTPS. First of all, what is digital abstract and digital signature under popular science?

6.1 what is a "digital summary"

When downloading files, we often see that some download sites also provide "digital summaries" of downloaded files for downloaders to verify that the downloaded files are complete, or whether they are "exactly the same" as the files on the server. In fact, the digital summary is the use of a single Hash function to encrypt the plaintext "abstract" into a fixed length (128bit) ciphertext, this series of ciphertext, also known as digital fingerprint, it has a fixed length, and different plaintext summary into ciphertext, the results are always different, and the same content information must be the same.

Therefore, it may be more appropriate to call "digital summary" as "digital fingerprint". "Digital summary" is the root cause of HTTPS's ability to ensure data integrity and tamper-proof.

6.2 Digital signature-a 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 own private key. The encrypted digest will be sent to the receiver as a "signature" of the message together with the message The receiver first uses the same hash function as the sender to calculate the message digest from the original message received, and then uses the sender's public key to decrypt the attached digital signature of the message. if the two digests are the same, then the receiver can confirm that the message was sent from the sender and has not been omitted or modified!

This is what can be done by combining "asymmetric key encryption and decryption" and "digital digest" technology, which is what people call "digital signature" technology. In this process, the process of generating a digest of the transmitted data and encrypting it with a private key is the process of generating a "digital signature". The encrypted digital digest 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. The server compares the original data signature according to the checkCode sent by the user and itself, so as to confirm whether the data has been tampered with in order to maintain the integrity of the data.

After reading this, the article "Web login case analysis" has been introduced. If you want to master the knowledge points of this article, you still need to practice and use it yourself to understand it. If you want to know more about related articles, welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.