1. Timestamp-based solution
1. For a normal http request, the response time is generally completed within 5s, and basically will not exceed 60s. The App sets the threshold according to the response time of its own interface. 2. Each time the client initiates a request, it
carries the current time.
3. The server After receiving the request, verify the difference between the client timestamp and the server timestamp. If it exceeds 60s, it is regarded as a replay attack.
Advantages and disadvantages: The implementation is simple and effective, but within 60s, hackers can still implement replay attacks, and the time stamp Better to add salt.
2. Random number-based solution
1. Every time the client initiates a request, it needs to carry a random number id (unique is required)
2. After receiving the request, the server first checks whether the random number id carried by the user exists or not, and stores the random number id In the database or cache server, there are: it is considered to be a replay attack.
Advantages and disadvantages: the implementation is simple and effective, but as the number of requests increases, the stored data will become larger and larger.
3. Solution based on serial number
1. The client and the server add a progressively increasing integer to the message. As long as a message with a discontinuous serial number is received, it is determined that there is a replay threat.
Advantages and disadvantages: The advantage is that time synchronization is not required, and the amount of information saved is smaller than that of the random number method; the disadvantage is that once the attacker successfully decrypts the message, the serial number can be obtained, so that the serial number is incremented each time to deceive the authentication terminal.
4. Solutions based on timestamps and random numbers
1. For a normal http request, the response time is generally completed within 5s, and basically will not exceed 60s. The App sets the threshold according to the response time of its own interface. 2. Each time the client initiates a request, it
carries the current timestamp and random number id
3. After receiving the request, the server first checks the difference between the client’s timestamp and the server’s timestamp. If it exceeds 60 seconds, it is considered a replay attack. If it does not exceed 60 seconds, it checks whether the random number id carried by the user is Existence, non-existence, storing the random number id in the database or cache server, if it exists, it is considered a replay attack.