Whether HTTPS data encryption to prevent replay attacks?
No, encryption can effectively prevent the plaintext data being monitored, but it could not prevent replay attacks.
Anti-replay mechanism
We design the interface when the interface is user intercepted a fear for replay attacks. What replay attack is it? Is to re-send your request intact once, twice ... n times, the normal requests are entered into the normal logic validation, if this is the normal logic into the database operation, then once inserted into the database of written statements well, there are a number of duplicate data may occur. Once the query operation is relatively slow, it could lead to blocking and other databases.
Payment interfaces, or interfaces will result in the loss of purchasing
need to do anti-replay mechanism to verify the request.
timestamp+nonce
We used to prevent replay mechanism replay mechanism is to use the timestamp and nonce to do.
timestamp indicating a request for current timestamp, and the timestamp of course, the server timestamp corrected. We expect normal request with the timestamp parameters are different (expected to be at most normal people only do one operation per second). Stamp with each request and the current time can not be more than a certain predetermined time. Such as 60s. Thus, even if the request is intercepted, and you can only replay attack in the 60s. Expired.
But this is not enough, there is still time for the attacker 60s. So we need to use a nonce, nonce.
nonce is a case where the client according to the generated random enough, such as md5 (timestamp + rand (0, 1000)); the UUID may be used, there is a requirement that, under normal circumstances, in a short time (for example 60s) Continuous generating a nonce case two identical almost zero.
Server
When the server for the first time received the nonce to do the following acts: 1 redis to find whether there is key for the nonce: {nonce} of string 2 If not, create the key, the key to failure time and verify timestamp failure of the same time, such is the 60s. If there are 3, the key described in the 60s has been used, then the request can be determined that the playback request.
Example
So, for example, the following request:
HTTP: //a.com uid = 123 & TIMESTAMP ...?
This request is meaningful uid parameter we really need to pass a
timestamp, nonce, sign signature and are designed to prevent replay use.
timestamp is the time to send the interface, nonce is a random string, sign is uid, timestamp, nonce (for some rest style api, I also recommend the url into the sign signature). The signature method may be md5 ({Miyao} key1 = val1 & key2 = val2 & key3 = val3 ...)
the server receiving the request: a verify sign the signature is reasonable, attestation request parameter is not halfway tampered 2 revalidation timestamp has expired to prove whether the request is in the last 3 to verify nonce 60s recently been issued has been proved that reproduction request in the request is not 60s
level can also be used in web page added token way, phone code, sliding verification code and other ways to prevent attacks