javascript - Some websites use js to irreversibly encrypt the password in the password box when the user submits the login, and then submits it. Is this necessary? What are the advantages and disadvantages?

The process of these websites is roughly like this:

When user registers:

1. User fills in password

2. User clicks submit

3. Encrypt the password on the front end before submission

4. Encrypt the password before storing it in the database

When user logs in:

1. User fills in password

2. User clicks submit

3. Encrypt the password on the front end before submission

4. Transfer the password to the server and encrypt it again

5. Compare the passwords in the database

I think this only prevents people with ulterior motives from obtaining your clear text password, but they can still use the intercepted cipher text to construct a login request without knowing the clear text password

However, there are still some websites (http websites) doing this, so is it necessary to do this? What are the pros and cons?

This obviously cannot replace https

Reply content:

The process of these websites is roughly like this:

When user registers:

1. User fills in password

2. User clicks submit

3. Encrypt the password on the front end before submitting

4. Encrypt the password before storing it in the database

When user logs in:

1. User fills in password

2. User clicks submit

3. Encrypt the password on the front end before submitting

4. Transfer the password to the server and encrypt it again

5. Compare the passwords in the database

I think this can only prevent people with ulterior motives from obtaining your clear text password, but they can still use the intercepted cipher text to construct a login request without knowing the clear text password

However, there are still some websites (http websites) doing this, so is it necessary to do this? What are the pros and cons?

This obviously cannot replace https

I thought about front-end encryption when I was doing identity authentication in the past, but I thought it was useless and of little use.

For the server, the front-end encrypted data is the user’s password. Once the packet is captured, the hacker can obtain the front-end encrypted data and can also pretend to log in

If you have high security requirements, it is better to use https, although it may also be attacked.

If the whole site is https, all http resources will cause alarms, because HTTPS requires the entire process to be encrypted, even for a picture.

Encryption on the front end can ensure that the password is the ciphertext of the transmission during the transmission process. In other words, no one except the password owner knows what the password is, not even the person who developed the program.
In this way, even if someone catches your http package, they cannot decrypt it (except for brute force cracking)

The only advantage is that if your database is stripped, it will not affect the user's password on other websites (commonly known as database stuffing)
Others are of no use. Just replay the attack to fake the user login, such as It is said that in the case of http, a man-in-the-middle attack intercepts the user's password. I don't need to know what the original password is. I only need to send the request again with the same ciphertext. I can also fake the user login. I can understand the encryption of the https website. That is The only benefit I said
The http website does this by taking off its pants and farting. It does nothing to ensure user safety. Moreover, if the front-end encryption algorithm is reversible, it is useless. I agree that the ciphertext can be known by restoring the js encryption method.