The hash is generated by the client using the client specific secret key using the hash_hmac inbuilt method. This hashed value is included in the request header. Request which include this hash value also have a time stamp field set.
The server generates it’s own hash based on the request content and the client specific key( the client specific details are known to server from the header).
The hash generated by the server is matched to the hash received from the client. Both need to same for authorization success.
The received hash is stored in the Redis. We set a TTL equal of 300 seconds.
The server also uses the timestamp to check that the request is not repeated in last 5 minutes based on the based on the Redis Key and the timestamp in request.
If the timestamp sent is less than 300 secs old the server discards the request.
If the hacker tries to change this timestamp for an old request to repeat it then the received hash will not be same.
This version of HMAC which also prevents Replay Attacks as the received hash is stored for 5 mins. So obviously the same request can’t be repeated within 5 mins.
A replay attack (also known as playback attack) is a form of network attack in which a valid data transmission is maliciously or fraudulently repeated or delayed. This is carried out either by the originator or by an adversary who intercepts the data and re-transmits it, possibly as part of a masquerade attack by IP packet substitution.
Another way of describing such an attack is: “an attack on a security protocol using replay of messages from a different context into the intended (or original and expected) context, thereby fooling the honest participant(s) into thinking they have successfully completed the protocol run.”