1. The use of hash needs to be combined with specific code to know what to do with it. Generally speaking, is used as a summary of some data to verify data integrity ;
.
2. Why is the public key updated? When the key is not disclosed, the public key is used for disclosure, and anyone can hold it.
3. irreversible that's not encryption. Abstracts such as MD5 ( hash ) algorithms are irreversible, but how to decrypt them since they are irreversible?

in addition, doesn't the of the subject violate the principle that the password is known only to God and himself what does the password refer to in this sentence?

if you are talking about login password, then:
when registering:

1. assign a salt value to the user salt
2. deal with plaintext passwords md5 (pwd + salt) ( for example, free definition of specific practices )
3. salt value and processed password are stored in the database

when logging in:

1. use the plaintext password obtained and the salt value of the user in the database to process md5 (pwd + salt)
2. compare the processing result with the password of the database (non-plaintext)

for the CSDN event, after the above process, the passwords obtained by taking off your pants are all processed values, and because it is a summary algorithm, it is difficult to get the original password through (pwd_md5 + salt). At the same time, the server does not need to know what your plaintext password is to know whether your password is correct .

as for the security of plaintext passwords during login, if you don't consider HTTPS , you can run naked or manually cover things like RSA , or you can improve the above process:
when registering:

1. assign a salt value to the user salt
When the
2. page submits the form, replace the password with sha1 (pwd) calculate the SHA1 digest for plaintext passwords first
3. the server processes passwords md5 (pwd + salt) the passwords transmitted from the network are no longer plaintext passwords, but the server does not need to care about these
4. salt value and processed password are stored in the database

when logging in:

When the
1. page submits the form, replace the password with sha1 (pwd) calculate the SHA1 digest for plaintext passwords first
2. use the password obtained and the salt value of the user in the database to process md5 (pwd + salt) in the same way as when registering
3. compare the processing result with the password of the database (non-plaintext)

the second step of registration and the first step of login can be postponed one step later, because it suddenly reminds me that you need to check whether the password meets the requirements (length, case, numbers, etc.). If you do these rule checks only at the front end, you can be bypassed by a construction request.
with this in mind, transmits plaintext directly without considering HTTPS or the password after encrypts is acceptable.

1. The public key is updated periodically? Do you see it change regularly? Don't take it for granted, don't guess that it is updated regularly and ask it as a fact. You do see it change regularly and ask this point again
2. When you go to see the login of google, it is directly a clear text of the agreement, does it violate the principle that only God and you know the password? Just because the server takes it doesn't mean the server needs to save it