What is the current mainstream and reliable login password encryption process?
how reliable is the process of password authentication for user login? (do not discuss channel encryption on https)
1. The front-end plaintext passes the password to the back-end for encryption, and compares the processed ciphertext with the database to return the result;
2. The front end encrypts the password and transmits the ciphertext to the back end. The back end compares the ciphertext with the database and returns the result.
3. The front end encrypts the password and transmits the ciphertext to the back end. After decrypting the ciphertext, the plaintext is compared with the database to return the result.
4. The front end encrypts the password and transfers the ciphertext 1 to the backend. After decrypting the ciphertext, the backend encrypts the plaintext. The ciphertext 2 is compared with the database to return the result.
5. The front end encrypts the password and transfers the ciphertext 1 to the back end, and the back end encrypts the ciphertext 1 for the second time, and then compares the ciphertext 2 with the database to return the result.
6. Other appropriate ways
consider scenarios such as database disclosure and data interception during data transmission;
ask for detailed flow;
in addition, please attach encryption algorithms, such as RSA,MD5, etc.
if the requested data can be intercepted in the middle, then any encryption you do for the password at the front end is equivalent to useless work. Because your backend can't tell whether the request is really sent by the front end or the second request after it is intercepted.
if the backend does not do any processing to the data sent from the front end and directly compares it to the database, then your data will be leaked and you will be running naked.
therefore, there must be a back-end encryption algorithm, and the encrypted data is stored in the database, which is compared with the database after being encrypted by password.
as for the front end, if the front end code is not cracked, you can do a reversible encryption (des,aes). The password is encrypted and passed to the background, and the background decrypts the original password data. Then the encrypted data is obtained according to the fixed algorithm (irreversible) and compared with the database. In this way, at least the front-end code cannot be cracked, and what they get after intercepting the ciphertext is the reversible encrypted ciphertext.
the front end is encrypted with salt and sent to the backend, and the back end continues to add salt encryption to match the database.
does not need to be decrypted.
if you have the ability, write a set of encryption algorithm by yourself, encrypt the password at the front end, and confuse the js package / code in the encryption process, so that people can't see the algorithm as much as possible. The backend decrypts it according to the agreed algorithm.
or asymmetric encryption. The back end provides an interface to dynamically return a public key to the front end, which is encrypted according to the public key. After receiving it, the backend uses the private key to decrypt it.
you can refer to the login process of websites such as iqiyi and Youku. They encrypted the password and transmitted it.
the backend must need to be decrypted, otherwise front-end encryption is meaningless.
before, passwords are not encrypted. Basically, sha256 (salt + password) is stored in the database. Every time password is sent from the front end, the hash calculated at the back end is compared with the database value.
and there is no problem with transmitting the secret key based on https. Even if the man in the middle attacks, you still get ciphertext
.
