- 1. A simple HTML example to see user information security
- 2. HTTPProtocol Transfer Exposes User Password Fields Directly
- 3. Can cryptographic algorithms guarantee password security?
- 4. The conclusion is that no matter HTTP or HTTPS, ciphertext must be transmitted.
- 5. That would be great. This saves money on HTTPS. Is that true?
- 6. It’s not easy! But don’t be too happy. Be careful that the data is tampered with.
- 7. summary
1. A simple HTML example to see user information security
Standard HTML grammar supports the use of & lt; input & gt; & lt; / input & gt; tags to create HTTP submission attributes. In modern WEB logins, the following forms are common:
<form action = "http://localhost:8080/Application/login" method = "POST"> Username: & lt; input id = "username" name = "username" type = "text" / & gt;Password: & lt; input id = "password" name = "passw"Ord "type=" password "/>< button type= "submit" & gt; login & lt; / button & gt;< /form>
formWhen submitting a request, the form obtains the attribute of name in the input tag of the form and passes it to the background as a parameter in the body of the HTTP request for login verification.
For example, if my account number is user1 and password is 123456, then the HTTP request I send to the background when submitting the login is as follows (Chrome or FireFox developer tool capture, need to open Preserve log):
You can find that even if the password field is black dot, the local machine still intercepts the request in plain text.
2. HTTPProtocol Transfer Exposes User Password Fields Directly
In the process of network transmission, the sniffed message will directly endanger user information security. Taking Fiddler or Wireshark as an example, it is found that the captured HTTP message contains sensitive information:
3. Can cryptographic algorithms guarantee password security?
WEBThe front-end can encrypt the password field through some algorithm, and then submit the password as the content of Http request, which includes symmetric and asymmetric encryption.
Symmetrical Encryption: Symmetrical cryptographic coding technology is used, which is characterized by file encryption and decryption using the same key encryption.
Asymmetric encryption: Two keys are required, public key and private key. The public key and the private key are a pair. If the data is encrypted with the public key, only the corresponding private key can be decrypted; if the data is entered with the private key, the data can be decrypted.Row encryption, then only the corresponding public key can be decrypted.
3.1 Using symmetric encryption
Encryption and decryption seem to be a good way after consulting in the front and back office. For example, the front office uses a simple method of string displacement + string inversion (for example, of course not so simple). Then, if the original password 123456 shifts first:
So this simple method seems to confuse the original password, and it is easy to restore the password by doing the opposite operation in the background. But there are two shortcomings:
The front-end and back-end encryption and decryption need to modify the code at the same time.
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 Asymmetric Encryption HTTPS Secure?
Asymmetric encryption has the existence of public key and private key. Public key can be obtained at will. Private key is used to store public key decryption locally. It seems that the mechanism of public key and private key can guarantee the transmission of encryption and even the HTTPS which is still in use is based on this principle.
But must HTTPS be secure? HTTP has two possible risks:
HTTPSIt can ensure that the information in the transmission process is not intercepted by others, but after careful consideration, HTTPS is the application layer protocol, and the lower layer uses SSL to ensure information security, but at the client and server side, ciphertext can also be intercepted.
HTTPSIn the transmission process, if the client is maliciously guided to install the WEB trust certificate of the “middleman”, then the “middleman attack” in HTTPS will also disclose the plaintext password to others.
4. The conclusion is that no matter HTTP or HTTPS, ciphertext must be transmitted.
Considering that HTTPS can not guarantee user password information, we should consider protecting password on the application layer. That is to say, writing code to control password instead of relying on specific protocol. It is easy to think of using irreversible encryption hash function MD5 (string) to protect password information.When a user registers to enter a password, he stores the MD5 (password) value, and first carries out MD5 (password) on the WEB end, then transfers the password to the background, comparing it with the ciphertext in the database (PS: MD5 function, in the case of a specified number of digits, compares the same number).The string operation has the same value. The advantages are obvious:
It ensures the security of password information in user database.
In any case, the user’s ciphertext will not be cracked out of the original password in the transmission process.
Simple and efficient, implementation and coding is not difficult, all languages provide MD5 support, rapid development.
5. That would be great. This saves money on HTTPS. Is that true?
Back to the example at the beginning: the user enters user1 and password 123456. Under any protocol, you can see that the actual HTTP/HTTPS message sent after MD5 processing is as follows:
Yes, the encrypted login was successful. However, when we celebrated password security, we found that the account money suddenly disappeared. Why is that? Hackers laugh happily: because they don’t have to get your password plaintext, if you intercept your password ciphertext directly, then send it to the server is not the same.Can you login? Because the database is not MD5 (password) the same ciphertext? HTTP requests are forged and can be logged in successfully to grab other data or transfer balances.
What about this? It’s not really difficult. There are many solutions. In fact, the principle is similar: the server cache generates random validation fields and sends them to the client. When the client logs in, the field is passed to the server for validation.
5.1 Scheme 1: Verification Code
MVCScene. The controller will encapsulate the data model into View, which is a Session-based connection that allows access to information in Session. Then we can use some open source verification code generation tools, such as Kaptcha in JAVA, on the server side.Store and generate a validation code value and a generated picture of the validation code, encode the picture with Base64, and return it to View, decode Base64 in View and load the picture, and then compare it when the user logs in next time.
5.2 Scheme 2: token token
Front-end and back-end separation scenarios. Now the very popular development model of front-end and back-end separation greatly improves the development efficiency of the project. Responsibility and division of labor are clear, but 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 acts as key, generates random tokens (such as UUID) to be cached in Redis as value, and returns token to the client. When the client logs in, it completes the validation and deletes the cache record in Redis.
So every time token is authenticated from the server, it can ensure that HTTP requests are sent back from the front end, because token will be deleted and reset after each login, which will lead to hackers trying to replay account password data information when landing, leading to unsuccessful login.
In a word, even if I get the password and account number, I can’t log in, because if the request does not contain the token of background authentication, it is an illegal request.
6. It’s not easy! But don’t be too happy. Be careful that the data is tampered with.
The password is encrypted, and the hacker can’t see the plaintext. With Token, the landing process can no longer be intercepted and replayed. But think about this situation. You need four fields: account number, password, amount and token to make online payment on a treasure. Then you pay one yuan when you pay.Money bought a bag of mailed raccoon noodles. When a treasure was settled, you found that your account balance was withheld by 10,000 yuan. What’s going on here?
Because even if hackers don’t log in and do not operate, they will destroy it: when the request is routed to the hacker’s side, they intercept the data packet, and then don’t say they don’t log in. Anyway, the account password is right and token is right. Then they can change the field of the data packet to destroy it, so they can do mone.Y changed to 10,000 and passed it on to the server. As a victim, he stepped on the pit for no reason. But how can this be solved? In fact, the principle is similar to the digital signature mechanism in HTTPS. First, what is digital digest and digital signature under popular science?
6.1 What is a “digital digest”
When we download files, we often see that some download sites also provide a “digital summary” of the downloaded files for downloaders to verify whether the downloaded files are complete, or whether they are the same as the files on the server. In fact, the digest is the plaintext that will need to be encrypted by using a single Hash function.”Abstract” is a series of ciphertext with fixed length (128 bits). This series of ciphertext is also called digital fingerprint. It has fixed length, and different plaintext abstracts are ciphertext. The results are always different, and the same content information must have the same abstract.
Therefore, “digital digest” called “digital fingerprint” may be more appropriate. “Digital digest” is the fundamental reason why HTTPS can ensure data integrity and tamper-proof.
6.2 Digital Signature–Water-to-Channel 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 text of the message, and then encrypts the digest with its own private key. The encrypted digest will be sent to the receiver as the signature of the message and received together with the message.First, the sender calculates the message digest from the received original message using the same hash function as the sender, then decrypts the additional digital signature of the message with the sender’s public key. If the two digests are the same, the receiver can confirm that the message was sent from the sender without being omitted or modified.This is the combination of “asymmetric key encryption and decryption” and “digital digest” technology can do, which is what people call “digital signature” technology. In this process, the process of generating digest and using private key to encrypt the transmitted data is the process of generating digital signature, which is encrypted digest.That’s digital signature.
Therefore, we can get a field checkCode by signing username + MD5 (password) + token mentioned in the previous case on the WEB side, and send checkCode to the server according to the ch sent by the user.EckCode and the original data signature are compared to confirm whether the data has been tampered with in order to maintain the integrity of the data.
Seemingly very simple WEB login, in fact, there are also many security risks. These processes of security improvement are encountered in a practical WEB project. The above analysis evolution is a solution proposed in response to the project security inspection. There will be many shortcomings in some cases. I hope we can work together.Discuss and make progress together!
Synchronized publication of articles: https://www.geek-share.com/detail/2753198000.html