Thoughts on Web Service replay attacks

When talking about transactional services in the afternoon, in addition to digital signatures for certificates, we also talked about replay attacks.

Replay attacks can be identified by serial numbers.

The serial number is divided into: 1. The service caller issues the serial number. 2. Issue a service provider.

Serial number generation methods are divided into two types: 1. No duplicates, random issuance. 2. increment. 3. timestamp.

 

If the issuer chooses to be a service provider, the original session interaction will become twice, increasing the complexity and failure rate. Therefore, it is best to issue the service caller. If the generation method is set to 1, the storage cost is very high (the method issued by the Service caller must be fully saved on the service caller side. If the verification is not used on the service provider side, it will also be recorded and eventually saved in full. Service provider issuing method. The serial number is only stored on the service provider side, but it is also full .) Select 2 as the generation method. No matter which issuance method you select, you only need to save the serial number of the last time. However, you need to protect the concurrent access control for multithreading and clusters, prevent the service from being rejected due to the inaccurate order of concurrent access. Select 3 as the generation method. No serial number is required for any issuance method. During verification, the size of the tolerable time window is set to determine whether the timestamp is valid. Note the time difference between the client and the server. When the time difference exceeds the tolerable time window, each request may be rejected as an invalid request.

Here, my idea is to combine two methods to prevent replay attacks, that is, to ensure the resource usage is controllable and the complexity of the system is not high: the service caller issues a serial number, at the same time, the generation method adopts the timestamp method. The server verification process is as follows:

 

 

The service validity period can be defined by yourself (for example, half an hour or one hour). The reference is the maximum tolerable time difference between the client and the server, the second is your own Storage Estimation. If the storage is larger, it can be wider. This design adopts non-repetitive verification within the tolerable value. After all, the timestamp method is not repeated, this reduces the difficulty of sequential control caused by concurrency and parallelism in a short period of time, and uses incremental verification after the tolerable value, which can reduce the storage pressure on serial numbers, you can consider the maximum tolerable time based on your storage capacity.

Welcome to discuss...