Pan Jianxu is a software engineer at www.bigsec.com. 3 years of full-stack development experience, responsible for front-end development and architecture of core products in the early stage of EON.
Front-end security is a part of Web security, common security problems will be XSS, CSRF, SQL injection and so on, but these have been quite high attention in the field of engineers and there are very mature solutions. So today we’re just going to talk about front-end “encryption,” a job that some people don’t think makes sense. As controversial as things are, Tristan, let’s talk about “encryption” of data in transit at the front end.
What algorithm should we use to encrypt the data transmitted at the front end and how to organize the whole encryption process? There are several ways to do this:
• JavaScript encrypted after transmission
• Encrypted transmission within the browser plug-in
• Https transport
The first is not encryption in the strict sense, but rather an application of information summarization, using the word encryption for the sake of exposition. Before proceeding, a few concepts need to be briefly introduced:
Hashing and encryption
In the figure above, it is clear that hashing and encryption are two different things, with two main differences:
Hash algorithms are commonly used for data digests, producing text of equal length. The length of the ciphertext generated by the encryption algorithm is related to the length of the plaintext. Hashing is irreversible, whereas encryption is reversible.
In encryption algorithms, it is divided into symmetric encryption and Asymmetric encryption. Asymmetric encryption algorithms have different encryption keys and decryption keys, including private keys and public keys. RSA is known as an asymmetric encryption algorithm. In symmetric encryption, encryption and decryption use the same key, such as AES/DES. In terms of performance, asymmetric encryption is much slower than symmetric encryption.
In HTTPS, asymmetric encryption algorithms are used in authentication and symmetric encryption algorithms are used in non-authentication.
Meaning of front-end encryption
Under THE HTTP protocol, data is transmitted in plaintext, and the network sniffer can directly obtain the data during transmission. Such as the user’s password and credit card related information, once obtained by middlemen, will bring great security risks to users.
On the other hand, during unencrypted transmission, an attacker can alter data or insert malicious code, etc. HTTPS was born to solve the problem of man-in-the-middle attack, but now the use of HTTPS in China is not optimistic, mainly due to cost or performance considerations.
Q
So the question is, if HTTP protocol is still used, how to ensure a certain degree of user data security?
A
Front-end encryption, that is, data is hashed or encrypted using public keys before it is sent. If the data is retrieved by an intermediary, it is no longer clear text.
Imagine in today’s popular public WIFI, once the traffic of an AP is hijacked by an attacker, if the password and user name are in plain text, then the attacker will easily use these data to Replay login. To make matters worse, many users use the same account information on different sites, and users’ privacy is lost.
As a website service provider, website designers and developers should provide relatively safe services for users, which is a responsibility and a feeling.
In addition, if the front end uses hash algorithm, it can not only help the back end to share part of the calculation pressure, but also increase the cost of database collision. The detailed discussion will continue below.
How to encrypt
As mentioned earlier, there are two ways to use JavaScript encryption: one is to use hash for information summarization, and the other is to use asymmetric encryption. Both methods are used in well-known sites in China. Let’s take a closer look at the encryption process and discuss how to deal with different scenarios.
1 Hash “encrypt”
To avoid plaintext risks during transmission, the front-end can encrypt sensitive data, such as passwords, before sending it. Due to the irreversibility of the hashing algorithm, the middleman cannot get the user’s password information from the intercepted data.
There is a problem, however, that the attacker can still use the obtained hash value to log in directly. How do you avoid man-in-the-middle replay attacks using front-end encryption? With that in mind, let’s review how users are authenticated in the background.
Many site background for user password processing is also using hash algorithm, on the one hand, because there is no need to decrypt the ciphertext into plaintext to compare the password, on the other hand, once the encryption algorithm and key disclosure, then the entire user database is equivalent to plaintext storage. If the front end passes clear text, it is hashed into the database at registration time. During login, the password hashes are compared with the database data. If they are the same, the password is correct.
Would it solve the problem if we used Salt? If the front end passes the hash with the salt added, we need to have the same salt on the back end, hash it with the encrypted password of the database, and compare it with the hash passed from the front end. A comparison of the two processes is shown below:
It’s easy to see that if the Salt isn’t different every time you log in, then an attacker can still log in directly with an encrypted password, so dynamic Salt must be used. Dynamic Salt can be done in many ways, either as a dynamic Token or directly using an off-the-shelf captcha. This is the use of verification code on the background system changes small and the effect is good, let’s see how to combine the verification code for front-end encryption.
2 Use the verification code to perform front-end encryption
The front end hashes the password first, and then hashes the verification code entered by the user. The result is sent to the server as the password field. The server verifies that the verification code is correct before password authentication. If the verification code is incorrect, the server returns an error message.
This practice ensures that the data is secure during transmission and cannot be played back even if an attacker gets hold of the data. Graphical captchas add to the difficulty. On the other hand, this practice greatly increases the cost of collision storage.
Front-end encryption to a certain extent to ensure the data security in the process of transmission, so will there be on both ends (client and server) security help?
Yes, use some front-end encryption means, you can increase the difficulty of data cracking after dragging the library. But the verification code method introduced before does not have such a function, because the data store is still the result of the plaintext password hashing, so the attacker can bypass the front-end encryption, can be directly brute force cracking.
3 How to increase the difficulty of data cracking after dragging and storing
What kind of front-end encryption method can increase the data cracking difficulty after dragging the library? To consider from two aspects, one is to reduce the speed of cracking, the other is to need front-end encryption results to affect the data storage of the database. The time of brute force cracking is negatively correlated with hashing speed.
We know that brute force cracking is using the same algorithm to run through commonly used groups of characters, and if the results are the same then the plaintext is guessed. The faster the algorithm, the faster the hack. For example, MD5 encryption takes 1 microsecond at a time, so an attacker can guess about 1 million phrases a second.
Therefore, in order to slow down the cracking speed, we need to increase the cracking time. A direct method is to use a slower algorithm. We can replace the commonly used MD5 algorithm with bcrypt, PBKDF2 and other slow algorithms.
For the data storage that requires front-end encryption results to affect the database, that is, back-end encryption uses front-end encryption results as plaintext passwords, so the passwords in the database are the results of front-end hashing and back-end encryption.
Because the slow algorithm will increase the server calculation pressure, when we put part of the hash work to the front end, which slows down the encryption speed, reduces the server pressure, but also completes the front-end encryption work.
Slowing down the encryption speed can degrade the user experience to some extent, which is one reason why some sites do not enable HTTPS. But because our front-end encryption will only be used for infrequently used logins and registrations, it will not affect the overall experience of the site.
In summary, we can use a slower algorithm and treat the result of the front hash as a plaintext cipher, which increases the cost of drag library cracking. Since the cost of cracking has increased, the cost of bumping libraries has also increased. To avoid the new dictionary that an attacker previously generated using the back and forth encryption, we need to add salt and update the salt value periodically. Here’s how to use an expired Salt:
Front-end encryption uses Salt periodically refreshed, hashes to generate ciphertext, and then after back-end encryption, ciphertext is used for comparison. The password hashes in the database change with the Salt, and the front and back end need to have a Salt update mechanism.
Reviewing the method of front-end hashing, it solves the man-in-the-middle attack replay and increases the difficulty of drag-library cracking. Although none of these methods can completely guarantee user safety, as a site server, you should treat the user as god. These methods are just a few lines of code, but they can avoid the risk of user account theft to some extent.
4 Asymmetric encryption
Above we discussed the front-end hash encryption and the application scenarios. For full security control, such measures are of little use to would-be attackers. We can then adopt stronger measures to secure sensitive data in transit.
It has been said before that encryption algorithms are divided into symmetric encryption and asymmetric encryption. Because of the transparency of the front end, it is impossible to use JavaScript to carry out symmetric encryption, so only asymmetric encryption is left.
After the author of a few days of research found that some goose some wave of part of the login page using asymmetric encryption to encrypt the password. All of these sites still use HTTP, which is a security measure to keep passwords safe.
5 concludes
The front end uses the public key to encrypt data, and the back end uses the private key to decrypt data into plaintext. The intermediate attacker has the ciphertext, and you can’t crack it without a private key.
One might point out that this set of security measures is useless once the encryption algorithm is broken. And JavaScript’s ability to generate secure random numbers is a problem, so it’s not really an HTTPS trade-off. In the absence of HTTPS, using JavaScript asymmetric encryption or plug-ins to encrypt communication is a better alternative, and the latter is better than the former.
Safety is more than feelings
As a front-end developer, we shouldn’t be obsessed with frameworks, and we shouldn’t be beaten back by what someone says doesn’t make sense. There is no such thing as a silver bullet. The same goes for security.
Therefore, it is very important to adopt a security solution according to the actual situation. Even if the solution is not 100% effective, we should not give up the 1% chance to guarantee the security of users.
