- The defense mechanism cannot rely on the clocks of the parties.
- The defense mechanism should work even when requests are not sequential.
- No party can store more than 1KB of data at any given time for the purposes of replay attack prevention (per session - see below).
- No requests must be sent for the purposes of replay attack prevention.
- Before the defense mechanism is used, another protocol is used to authenticate the first party and create a session. The session ID is included in every request of the above protocol.
- During the authentication protocol, up to 1KB of data can be sent to the first party for the purpose of replay attack prevention on the above protocol.
In what way does HTTPS handle replay attack prevention? How can this (the first described) protocol be made immune to replay attacks?
Considered Idea #1:
- A 256-bit secret is shared by the two parties during the authentication protocol.
- When party 1 makes a request, they include this secret in their message.
- Party 2 checks that this is the same value they have stored. If so, it is included in the response and this value is hashed and stored, replacing the previous value.
- Should the response be valid and contain the value sent, party 1 hashes the value sent and stores it, replacing the previous value.
- Steps 2-4 are repeated for every request and response.
The problem with this is that requests need to be sequential.
Considered Idea #2:
- Every time party 1 makes a request, a nonce is included.
- Party 2 checks if this nonce has been used before with this session id, if yes, it denies the request, if not, this value is stored. Party 2 includes this nonce in the response.
- Party 1 checks if the sent nonce is included in the response.
The problem with this is the large storage space needed.