How to prevent the front end from seeing the original password in the browser's network after calling the login interface?

for example, when we are shopping in JD.com, we have to log in first, open the browser console, enter the account number and password, and then click Log in. We will find in the browser network that the password field passed to the background is a string after a burst of encryption. I would like to ask all the bosses how JD.com did it.

May.07,2022

you can use js MD5 to send the password after MD5, but the JS source code can also be cracked when people with good intentions see it. There is no absolute security at the front end.
the backend cannot trust any data submitted by the front end


use RSA2 to encrypt with the public key using js at the front end, and decrypt it with the private key after transmitting to the background.

benefit: the ciphertext passed at the front end cannot be decrypted by the public key, even if the packet is caught, others cannot guess the original text (there is no absolute security.)

disadvantages: RSA is inefficient and the length of data that can be passed is limited.

suggestion: use https.


do a simple encryption. The backend gets it, decrypts it, and then matches the password.

for example, using sha256

front end, md5 user name gets a hash, use this hash as secret, use sha256 encryption password to get ciphertext, transmit username and ciphertext as login information
backend, md5 username gets the same hash, use this hash for left secret decrypt ciphertext with sha256 to get password, match database authentication login

this can actually be regarded as wearing a layer of clothes for the password, but it is not of much use for the attack. If the attacker can get the transmission plaintext, he can also log in with the encrypted password, so https can play a protective role.

Menu