preface

This series started with preparing yourself for an interview. Later found more and more sorting, almost 120,000 characters, finally decided to share to everyone.

In order to share the sorting out, I spent a lot of time, at least three times as much time as ONLY myself. If you like, welcome to collect, follow me! Thank you very much!

The article links

  • Front – end interview check and fill gaps -(1) tremble and throttling
  • (2) Garbage collection mechanism
  • (3) Cross-domain and common solutions
  • (4) Front-end local storage
  • (5) Rendering mechanism and redraw and backflow
  • Front – end interview -(six) browser cache
  • (7) XSS attack and CSRF attack
  • (8) Front-end encryption
  • (9) HTTP and HTTPS
  • Check and fill gaps in front interview –(10) Front authentication
  • (11) Front-end software architecture pattern MVC/MVP/MVVM
  • (12) From the input URL to the page to see the whole process (including three handshake, four wave detailed explanation)
  • Front – end interview leak -(13) memory leak
  • Front – end interview omission and filling -(xiv) algorithm and sorting
  • (15) Event Loop

Collection of articles:

The Index (120,000 character collection) contains more than a dozen other articles in the series written so far. The following new value-added articles will not be added in each link, strongly suggest that the comments like, pay attention to the collection!!!! , thank you! ~

Follow-up Update Plan

Design pattern, front-end engineering, project process, deployment, closed loop, vUE often test knowledge and other contents will be added in the future. If you think the content is good, welcome to collect, follow me! Thank you very much!

Ask for an extrapolation

At present, I am also preparing for job-hopping. I hope you and HR sister can promote a reliable front-end position in Wuhan! Email :[email protected]. Thanks! ~

Meaning of front-end encryption

This is an inescapable topic, and there are certainly many opinions. But in my opinion: the front-end encryption seems to make sense, but sometimes it doesn’t seem to “make sense “. But overall it makes sense, metaphorically speaking: does it make sense to put a lock on a door when most locks on the market can be picked in 20 minutes?

Significance: Over HTTP, data is transmitted in plaintext. During transmission, the network sniffer can directly obtain the data. For example, the user’s password and credit card information, once obtained by the middleman, will bring great security risks to the user. On the other hand, in the process of non-encrypted transmission, the attacker can change the data or insert malicious code. The meaning of front-end encryption is to hash or encrypt the data using a public key before sending it. If the data is accessed by a middleman, it is no longer in plain text.

Of course, there are other advantages: for example, to avoid printing logs such as the back end directly exposed plaintext password, and can avoid the plaintext database collision.

No “meaning “: front-end encryption, in fact, can only prevent a gentleman can not prevent villains. The control of the front-end system is completely in the hands of the user, which means that the user has complete control over what the front-end does. Even though front-end encryption does not protect against man-in-the-middle attacks, including HTTPS, there are all kinds of proxies, client proxies and server proxies in between. It’s hard not to get hijacked.

Here’s a quick word:

  • Encryption can not solve the replay problem, although you send the server is encrypted data, but after the hacker intercepts the encrypted data again, it is still verified through. Listen directly to your so-called ciphertext, and then use the script to make an HTTP request to log in. HTTP is transmitted in plaintext on the network. Both the proxy and the gateway can see all the data and can be sniffed on the same LAN. Encryption doesn’t make it any harder to attack because there’s no need for an attacker to decrypt the original password, and being able to log in means that the target has been achieved.
  • Since it is encryption, the encryption key and algorithm must be stored at the front end, and the attacker can get the algorithm and key by looking at the source code. Unless you’re making a browser plug-in that encapsulates the algorithm and the key, and then obfuscates the timestamp on the plaintext when encrypting it, even if a hacker intercepts the request data, it will quickly become invalid during the replay process.

To summarize:

  • 1, security is the front and back end of the need to do things, not front-end encryption, the back end of the matter.
  • 2,HTTPS is still necessary, as long as the correct use of HTTPS connection and server-side secure hashing algorithm, the password system can be very secure.

Here I just a simple comb, if there are doubts want to further explore (SI) to discuss (BI), you can read this article on the force

Several practices of front-end encryption

• JavaScript encrypted transmission (please refer to the following common encryption methods)

• Encrypted transmission within the browser plug-in (this is not used very much, so I won’t go into detail here)

• Https transport

The encryption algorithm

Unlike hash, which will be discussed later, Encrypt converts the target text into a reversible ciphertext of varying lengths. That is to say, the encryption algorithm is reversible and the length of the ciphertext generated after encryption is related to the length of the plaintext itself. Therefore, encryption is required if the protected data needs to be restored to plaintext at a later date.

The encryption algorithm is divided into symmetric encryption and asymmetric encryption.

Symmetric encryption

Symmetric encryption adopts the symmetric cryptography technology, which is characterized by using the same key for file encryption and decryption. In other words, both encryption and decryption use the same key. This method is called symmetric encryption in cryptography.

Symmetric encryption algorithm is simple and fast to use, the key is short, and difficult to decipher, in addition to the data encryption standard (DES), another symmetric key encryption system is the International data encryption algorithm (IDEA), it is better than DES encryption, and the computer function requirements are not so high.

Common symmetric encryption algorithms include DES, 3DES, Blowfish, IDEA, RC4, RC5, RC6, and AES

Note: Because of the transparency of the front end, do not use JavaScript for symmetric encryption of sensitive information such as login passwords. Because others can get the key from the front end, you can directly decrypt the information!

Asymmetric encryption

An asymmetric encryption algorithm 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 the data is encrypted with a private key, only the corresponding public key can be used to decrypt it. Because encryption and decryption use two different keys, this algorithm is called asymmetric encryption.

The basic process of asymmetric encryption algorithm to realize the exchange of confidential information is: Party A generates a pair of keys and discloses one of them to other parties as a public key; Party B obtains the public key and encrypts the confidential information with the key before sending it to Party A; Party A then uses another private key stored by itself to decrypt the encrypted information. Party A can only use its private key to decrypt any information encrypted by its public key.

Common asymmetric encryption algorithms include RSA, ECC (for mobile devices), Diffie-Hellman, El Gamal, and DSA (for digital signatures).

Hash encryption algorithm

Hash algorithm

A Hash is the conversion of the target text into a fixed-length string (or message digest). When the input changes, the resulting hash is completely different. Mathematically, a hash algorithm is a many-to-one mapping. For the target text T, the algorithm H can map it uniquely to R, and for all T, R has the same length, so there is no inverse mapping for H, that is, the hash algorithm is irreversible.

Based on the characteristics of the hash algorithm, it is suitable for the scenario where the protected data is only used for comparison validation and does not need to be restored to plaintext. The more common hashing algorithms are MD5 and SHA1.

We are familiar with the use of hash stored data example is: when we are a registered website, in the case of a forgotten password need to reset the password, the website will send you a random password or an email activation link, rather than the password sent to you before, this is because the hash algorithm is not reversible.

It is important to note that in Web applications, hash encryption is used on the server as well as in the browser.

Server hashing reasons: There is no need to decrypt the ciphertext into plain text to compare the password, and if the encryption algorithm and key are leaked, the entire user database is stored in plain text. If the front end passes it in plain text, it is hashed and stored in the database at registration time. During the login, compare the password hash with the database data. If the password is consistent, the password is correct.

Now, the main attack methods for simple hash algorithm are: search for collision method and exhaustion method. Therefore, in order to ensure the security of data, hash algorithm can be further encrypted on the basis of the common methods: salt, slow hash, key hash, XOR and so on.

Adding Salt

Salt encryption is an encryption method for system login passwords. It is implemented by associating each password with an N-bit random number called salt.

For the convenience of understanding: Here is a quote from this student’s article to explain:

Using SALT encryption, the basic idea is this:

  • 1. Sprinkle some salt on the password when the user signs up. Create a flavor. Remember the flavor.
  • 2. When the user logs in again, sprinkle salt on the input password and smell it to determine whether it tastes the same as the original one. The same will let you eat.

Since the same salt value is used to authenticate the password and to initially hash the password, the salt is stored in the database. And the value is randomly generated by the system, not hard-coded. This ensures the confidentiality of the object to be protected.

The time of registration:

  • 1. User registration, the system randomly generates salt value.
  • 2. Concatenate the salt and password to produce a Hash value.
  • 3. Store the Hash value and salt value in the database respectively.

The landing:

  • 1. The system finds the password Hash based on the user name.
  • 2. Hash the user password and salt value.
  • 3. Check whether the generated Hash value is the same as that in the database.

PS: The login shown in the picture is also not secure. The reason for this is salt value reuse, which will be mentioned later

When using salt encryption, the following two points should be paid attention to:

  • Short Slat

If the salt value is too short, an attacker can pre-make a query table for all possible salt values. For example, if the salt value is only three ASCII characters, then there are only 95x95x95=857,375 possibilities, increasing the likelihood of being attacked. Also, don’t use predictable salt values, such as user names, because user names are unique for one system and are often used for other services.

  • Salt Reuse

In project development, sometimes the salt value is written dead in the program or only randomly generated the first time, and then reused, this method of adding salt does not work. In the case of login passwords, if two users have the same password, they will have the same hash value, and an attacker can use a reverse table lookup to perform a dictionary attack on each hash value, making it easier to crack.

So the correct way to add salt is as follows:

(1) Salt values should be generated using a Cryptographically Secure pseudo-random Number Generator (CSPRNG), such as the RAND () function of C language, The resulting random numbers are highly random and completely unpredictable;

(2) Salt values are mixed into the target text and encrypted with standard encryption functions;

(3) The salt value should be long enough (experience shows that the salt value should be at least as long as the output of the hash function) and never repeat;

(4) The salt value is best provided by the server, and the front-end value is used.

Slow Hash Function

As the name suggests, a slow hash function makes the hash function so slow that the attack method is slow enough for the attacker to give up, often without the resulting delay being noticed by the user. The technology of key stretching is used to reduce the attack efficiency, and the realization of key stretching uses a CPU-intensive hash function. It looks a little dizzy ~ or pay attention to how this function is used!

If you want to use key extensions in a Web application, you need to set a low number of iterations to reduce the additional computational cost. We generally choose to do this directly using standard algorithms such as PBKDF2 or Bcrypt. PHP and Stanford university’s JavaScript encryption library both include PBKDF2 implementations, and you can consider using JavaScript in the browser, otherwise this part of the work should be calculated by the server.

Key hash

Key hashing is encryption by adding a key to a hash so that only someone who knows the key can authenticate it. There are currently two implementations: using the ASE algorithm to encrypt the hash value, and using the key HMAC algorithm to include the key in the hash string. To keep the key secure, you need to store it on an external system (such as a physically isolated server).

Even if the key hash is selected, it is necessary to salt or extend the key based on it. At present, key hashing is more used on the server, for example, to deal with common SQL injection attacks.

XOR

XOR refers to the “XOR operation” in logical operations. Return false if two values are the same, or true if they are not.

JavaScript’s binary operations have a special XOR operator, called ^.


1 ^ 1 / / 0

0 ^ 0 / / 0

1 ^ 0 / / 1

0 ^ 1 / / 1

Copy the code

The XOR operation has the property that if you XOR a value twice in a row, it returns the value itself. That’s why it can be used for information encryption.


message XOR key // cipherText

cipherText XOR key // message

Copy the code

The target text message, key is the key, the first time you execute XOR you get the encrypted text; One more key on the encrypted text will restore the target text, Message. To ensure the security of XOR, the following two requirements must be met:

(1) The length of key is greater than or equal to message;

(2) The key must be one-time and randomly generated each time.

The following uses login password encryption as an example to describe how to use XOR:

Step 1: Use MD5 algorithm to calculate the hash of the password;


const message = md5(password);

Copy the code

Step 2: Generate a random key value.

Step 3: Perform XOR operation to find the encrypted message.

function getXOR(message, key) const arr = []; For (let I = 0; let I = 0; i < 32; i++) { const m = parseInt(message.substr(i, 1), 16); const k = parseInt(key.substr(i, 1), 16); arr.push((m ^ k).toString(16)); } return arr.join(''); }Copy the code

As shown above, the password is encrypted using XOR and the one-time key key, so as long as the key is not compromised, the target text will not be cracked.

With all that said, the question arises: What kind of hashing algorithm should we use?

(1) Select proven mature algorithms, such as PBKDF2, etc.;

(2) The security version of Crypt;

(3) Avoid using encryption algorithms designed by yourself.

HMAC

I don’t know much about HMAC algorithms either. After reading several articles, I think it is similar to adding salt, except that salt is randomly generated in the back end (which seems to prevent replay attacks). Then the abstract is obtained by HMAC algorithm.

About HMAC algorithm part can read this article in detail, I am a poor student, read for a long time is not quite understand.=.=

The process is as follows:

  • 1. The client sends a login request
  • 2. The server returns a random value and saves the random value in the session record
  • 3. The client uses the random value as the key, performs HMAC calculation on the user password, and submits it to the server
  • 4. The server reads the user password in the database, performs the hMAC calculation using the key as that on the client, and compares the hMAC calculation with the result sent by the user. If the result is the same as that sent by the user, the user is valid.

Benefits:

  • Unlike the custom salt algorithm, the Hmac algorithm is common to all hashing algorithms, whether MD5 or SHA-1. Using Hmac instead of our salt algorithm can make the program algorithm more standardized and safer. (Excerpt from this article by Xuefeng Bigwig)
  • The other is password security, because you don’t know the key, so it’s impossible to get the user’s password

Supplement 1: Front-end encryption combined with verification code(It’s just a dynamic salting hash)

The front end first hashes the password, then hashes it with the verification code entered by the user, and sends the result as the password field to the server. The server verifies the verification code first and then the password. If the verification code is incorrect, the server returns an error message.

This practice ensures that the data is secure while the password is being transmitted, and that even if an attacker gets hold of the data, it cannot be replayed. Graphical verification codes make it even more difficult. On the other hand, this practice greatly increases the cost of colliding libraries.

The front-end encryption guarantees the data security in the transmission process to a certain extent, so will there be security help for both ends (client and server)?

Helpful, the use of some front-end encryption means, can increase the difficulty of data after the drag library. However, the verification code method does not have such a function, because the data inventory is still the result of the plaintext password hash, so the attacker can bypass the front-end encryption, can directly brute force cracking.

Supplement 2: Base64 encoding

People often talk about Base64 encryption. Is there Base64 encryption? No, it’s Base64 encoding.

Base64 is a representation of binary data based on 64 printable characters. It is used to express, transmit, and store binary data in situations where text data is normally processed, including email MIME, email via MIME, and complex data stored in XML. Mainly used to solve the need to cram non-printable content into printable content. The base64 method in js is as follows:

/ / 1. Coding
var result = Base.encode('good shotCat handsome! ');  //--> "c2hvdENhdOWlveW4hSE="

/ / 2. Decoding
var result2 = Base.decode(result); //--> 'shotCat! 'Yes, I am so shameless!!

Copy the code

Therefore, Base64 is suitable for encoding small pieces of content, such as digital certificate signatures, the contents of cookies, and so on. Base64 is also a look-up table encoding method and cannot be used for encryption. If encryption is required, use a professional encryption algorithm.

PS: For the front end, one of the most common uses of Base64 is image transcoding.

Addendum 3: Digital signature

Digital signatures are used to: confirm that the information comes from a specific subject and is complete and untampered. The sender generates the signature and the receiver verifies the signature.

Sender: First calculates a digest (hash) of the target text, signs the digest with the private key, and sends the target text and electronic signature to the receiver.

Recipient: Perform the following steps to verify the signature:

  • 1. Crack the electronic signature through the public key to get summary D1 (if the failure, the information source principal verification fails);
  • 2. Calculate the target text abstract D2;
  • 3. If D1 === D2, the target text is complete and untampered.

The difference between digital signature and asymmetric encryption:

  • Asymmetric encryption (encryption/decryption) : public key encryption, private key decryption.
  • Digital signature (signature/verification) : private key signature, public key verification.

HTTPS encryption

To avoid duplication, this is covered in detail in this series -HTTP vs. HTTPS

Thanks and Reference

  • What are we talking about when we talk about front-end encryption
  • You can say secrets. – Those front-end encryption methods we should talk about