there is no absolute security

first of all, md5 cannot be regarded as an encryption algorithm, because it is one-way and irreversible, and you cannot "decrypt" the password calculated by md5 to get the original plaintext password, but we do like to call it "encryption" when md5 has a relationship with the password. So even if the attacker knows that you used the md5 hash algorithm and intercepted your "encrypted" password, that is, md5 (password) (you might as well set the md5 hash function to md5 () , and the user's plaintext password is password ), the attacker will not be able to know the user's plaintext password backwards and can only violently guess the user's password.

secondly, even if an attacker does not know password , but only knows md5 (password) , it is enough that he can pass authentication by sending md5 (password) to the server. And the verification process is still plaintext comparison, only from the comparison plaintext password to the hash value of the comparison plaintext password. In order to solve this problem, someone proposes to add salt to the password: the server stores neither plaintext password password nor md5 (password) , but md5 (password) and salt , this salt is "salt". Each time the user logs in, the server sends it to the user as a dynamic salt that will not be repeated in a short time, and then the user sends md5 (md5 (password) + salt) back to the server. After the same operation, the server compares the results, and the consistency is verified. In this way, even if an attacker intercepts salt and md5 (md5 (password) + salt) , he cannot reverse md5 (password) . At the same time, salt becomes invalid once used, and the attacker cannot pretend to be a user by resending md5 (md5 (password) + salt) .

but there is a problem with the above practice (at least one problem): when setting a password, the user must tell the server md5 (password) , and the server will store md5 (password) in clear text. If md5 (password) is intercepted when setting the password, or if the server's database is compromised, the attacker will know md5 (password) , thus pretending to be the user passing the password authentication. Moreover, if the user uses the same password on other sites (which is very common), and other sites happen to use the same password authentication method, the attacker can obtain the user's authorization on multiple sites at the same time (hit the library). The root cause of this problem is that the designer did not get rid of the "plaintext password", using md5 (password) to replace the plaintext password is not much different from directly using the plaintext password, so someone suggested that we should not use md5 (password) , but use md5 (password + salt) instead. Here salt is not the previous salt , the front is "dynamic salt", and now we are talking about "static salt". To distinguish, use dsalt to represent dynamic salt and ssalt to represent static salt. Then the login method is as follows: the server stores md5 (password + ssalt) and the corresponding static salt ssalt (static salt is generated when setting the password). When logging in, the server dynamically generates random dynamic salt dsalt , sends ssalt and dsalt to the user, and the user sends md5 (md5 (password + ssalt) + dsalt) back to the server, and the server performs the same operation. If the results are consistent, the verification is passed. In this way, even if the attacker knows md5 (password + ssalt) , he can only break the user's account on one site, not the account of other sites that the user uses-- because the attacker cannot launch md5 (password) via md5 (password + ssalt) , and the static salt ssalt is also different for other websites. md5 (password + ssalt2) cannot be launched through md5 (password + ssalt1) .

if you don't want md5 (password + ssalt) to be intercepted, you can use asymmetric encryption (search details by yourself), but asymmetric encryption can do nothing against man-in-the-middle attacks (search details by yourself). In order to make asymmetric encryption resist man-in-the-middle attacks, people have developed a mechanism based on trust (self-search for details), but trust can be betrayed. So there is no absolute safety.

you can teach yourself cryptography if you are interested.

ah, first of all, let's deal with under normal circumstances, when you enter a password, you don't let anyone operate your computer, do you?
then as to why to hash and then save the database, it is to avoid the problem of stealing your database information. If there is no hashed password, once the account data on the server is stolen, then lawbreakers will have many kinds of operations to carry out bad behavior.

the main advantage of client-side encryption / digest / hash is to deal with weak passwords (salt is better) and to make attacks more difficult. It is better to use https and server-side encryption. Sometimes adding obstacles reduces the likelihood of attack. Do not let those who practice repeatedly messing with your server.

use asymmetric encryption algorithms. For example, everyone knows RSA.

what we need to do is to make it more difficult to guard against the robbers in the middle.
is encrypted before transmission, and the plaintext password cannot be seen by the middleman. This is a kind of protection, and it is even better to use https .
my own small projects like to encrypt passwords directly with things like md5, so that plaintext does not appear in the server log or in the database. js uses crypto-js . The tool site built with this library is md5 encryption check