The process for these websites is like this: when a user registers: when the user enters the password, the user clicks submit, and then encrypts the password before the front-end encrypts the password into the database, and then encrypts the password before logging on to the user: the user enters the password. before clicking submit, encrypt the password at the front end and pass the password to the server again... the process for these websites is like this:
User registration:
Password entered by the user
Click to submit
Encrypt the password at the front end before submission
Encrypt the password before saving it to the database.
When a user logs on:
Password entered by the user
Click to submit
Encrypt the password at the front end before submission
Pass the password to the server and encrypt it again
Compare the password in the database
I think this only prevents others from getting your plaintext password, but they can still use the intercepted ciphertext to construct a request for login without knowing the plaintext password.
However, it is still necessary for some websites (http websites) to do so? What are the advantages and disadvantages?
This obviously cannot replace https
Reply content:
The process for these websites is like this:
User registration:
Password entered by the user
Click to submit
Encrypt the password at the front end before submission
Encrypt the password before saving it to the database.
When a user logs on:
Password entered by the user
Click to submit
Encrypt the password at the front end before submission
Pass the password to the server and encrypt it again
Compare the password in the database
I think this only prevents others from getting your plaintext password, but they can still use the intercepted ciphertext to construct a request for login without knowing the plaintext password.
However, it is still necessary for some websites (http websites) to do so? What are the advantages and disadvantages?
This obviously cannot replace https
I used to think about front-end encryption when I was doing identity authentication. I felt very bad and it didn't do much.
For servers, the data encrypted at the front end is the user's password,Once a packet is captured, the hacker obtains the data encrypted on the front end, and can log on in disguise.
If the security requirements are high, you can still use https honestly, although it may also be attacked.
If you use full-site https, an alarm is triggered for all http resources, because HTTPS requires full encryption, even if it is an image.
The front-end encryption ensures that the password is the ciphertext transmitted during the transmission process. that is to say, no one except the password owner knows what the password is, even the developer does not know it.
In this way, even if someone catches your http packet, it cannot be decrypted (except for brute-force cracking)
The only benefit is that your database will not affect your password on other websites (commonly known as credential stuffing) when your database is deprecated)
Nothing else can be used. directly replay the attack to forge user logon. for example, the man-in-the-middle attack in http and the user's password are intercepted. I don't need to know what the original password is, you only need to send requests with the same ciphertext again to forge user logon.
I can still understand the encryption of https websites, which is the only benefit I have mentioned.
After the http website completes this process, it will take off your pants and fart. it cannot guarantee user security at all. Moreover, if the front-end encryption algorithm is reversible, it will be useless to do so, agree that the ciphertext can be known by restoring the js encryption method