Nonce, timestamp--solve replay-attack problem
A nonce is a random number generated by the server that is sent back to the client the first time the client requests the page, and the client gets the nonce, concatenates it with the user's password and makes non-reversible encryption (MD5, SHA1, and so on), and then converts the encrypted string and user name, Nonce, The encryption algorithm name is sent back to the server, the server uses the received user name to the database to search for the password, and then encrypts it with the client using the same algorithm, and then compares it with the encrypted string submitted by the client, if the two strings are consistent, indicating that the user identity is valid. This solves the problem that the user password plaintext is stolen, even if the attacker knows the algorithm name and nonce can not decrypt the password.
Each nonce can be used only once for one user, which prevents an attacker from using replay attacks because the HTTP message is invalid. The optional implementation is to save the nonce of each request to the database, and the client submits the request again to compare the nonce in the request header with the data in the database, and if the nonce already exists, proves that the request could be malicious. However, this solution also has a problem, it is likely that in two normal resource requests, the resulting random number is the same, so that the normal request is also considered an attack, as the number of random data stored in the database is increasing, the problem becomes obvious. Therefore, you need to add another parameter, timestamp (timestamp).
Timestamp is a string generated based on the current time of the server, which, together with the nonce, can represent a random number generated by the server at a point in time. This allows for the same random number generated, but because they generate different points of time, they are also counted as valid random numbers.
Again, as user access increases, the amount of nonce/timestamp/username data stored in the database becomes very large. For this problem, the optional solution is to set an "Expiration Time" for the data, such as storing data for more than one day in the database will be erased. If so, the attacker could wait a day before committing the intercepted HTTP message to the server, and the request would be considered valid because the Nonce/timestamp/username data had been purged by the server. To solve this problem, you need to set a time-stamp timeout, such as comparing the timestamp to the current time of the server, and if the time difference is considered invalid for one day.