How do you prevent replay attacks when using HMAC for authentication?

Timestamps are a common and reliable to way to prevent replays but there are several important traps to watch for. Firstly, the timestamp should be included in the input to the HMAC along with the message, otherwise an attacker could arbitrarily set a timestamp on an intercepted message. This approach also relies on closely synchronized clocks between the sender and receiver. Network Time Protocol (NTP) should be used but even then, a "buffer" range of acceptable time stamps is often needed to manage clock skew. Making this range too wide can give an attacker the opportunity to intercept and replay a message within a short time window. Finally, if an attacker can influence the clock on either device, this technique fails entirely.

An effective method to prevent replay attack is to use a challenge-response mechanism. The sender includes a challenge in each message, and the receiver must respond with the correct response based on that challenge. The challenge can be a unique value or a nonce generated by the sender for each message. The receiver verifies the response using the HMAC and the shared secret key. Since the challenge is different for each message, even if an attacker intercepts and tries to replay a previous message, they won't have the correct response for the current challenge. This approach adds an extra layer of security by ensuring that each message requires a dynamic response, making it more challenging for attackers to replay messages successfully.

use Idempotency key in one of the data field of incoming request body, and check if same idempotent key has been received in last 24 hours and if it is then that input is getting replayed

Randomly generated nonces (a "number used once") are a good way to prevent replay attacks so long as the receiver keeps a track of all nonces used so far and discards any messages containing a repeated nonce. A Cryptographic Secure Pseudo Random Number Generator CSPRNG must be used to generate the values and the nonce size must be large enough that the probability of a repeated value is negligible. The chance of a repeated value is approximately the square root of all possible nonce values so ensure the expected number of messages is much less than that!

When using a sequence number for replay prevention it is crucial that the number never repeat (i.e. a nonce). A counter that increments for every message is a good strategy but will result in repeated values if it overflows (e.g. ~4 billion unique nonces for a 32-bit counter) so choose a large enough number range. The sequence number should be included as an input to the HMAC tag so that it is cryptographically "locked" to each message. This makes forgery practically impossible. Finally, messages that arrive out of order can cause issues and clients may simply decide to discard messages or keep a small set of recent messages that it may still consider valid. The signal protocol provides a good case study in how to approach this.

Encryption doesn't prevent replay attacks! An attacker could intercept an encrypted HMAC value and send that to the receiver in the same way that they could with an unencrypted HMAC. The encryption provides secrecy but not replay prevention. A better strategy is to use a nonce (counter and secure random number generator) or a timestamp.

Verifying of an HMAC should always use a "constant-time" equality check. Standard string comparison will short-circuit as soon as a character differs and this can lead to timing attacks. Instead, an HMAC should always be verified using the verify function available in your favourite cryptography library.