Replay attacks
A valid old message can still be an unauthorized new action.
The idea
A replay attack reuses a captured valid message or token to repeat an action or obtain access. Cryptographic integrity alone may not distinguish a fresh request from a repeated one. Protocols use mechanisms such as nonces, sequence numbers, time windows, and replay-state checks where needed. The design should handle retries and clock uncertainty without accidentally accepting malicious repetition.
In practice
A signed request is rejected when its unique request identifier has already been used, while legitimate retries follow a defined idempotency rule.
A common misunderstanding
Encryption or a valid signature does not automatically establish freshness.
Check your understanding
What does a freshness mechanism add?
Think it through: Evidence that the request is valid for the current interaction and has not already been accepted in an unintended way.
A genuine message can be inappropriate a second time
A fictional ticket service accepts a signed request to issue one voucher. An attacker who captures that valid request may try to submit it again. Signature verification can succeed both times because the bytes are unchanged. The missing question is whether the operation is fresh and whether it has already been accepted.
The freshness mechanism should match the protocol. A challenge can bind a response to a current interaction. A sequence number can establish an expected order. A timestamp can limit a validity window but introduces clock assumptions and may still permit repetition within that window unless additional state is used. No single field automatically solves every replay case.
Legitimate retries complicate the design. A client may not know whether an operation succeeded after a timeout. Rejecting every repeat without explanation can harm usability, while executing every retry can duplicate effects. An idempotency design can associate repeated attempts with one intended operation and return a consistent result under defined rules.
Model one operation and its retry
For the voucher example, assign a dummy request identifier and draw initial acceptance, stored outcome, and a later retry. State whether the retry returns the original result or is rejected, and why it cannot create a second voucher. Add a request with the same identifier but different significant details as an expected conflict.
Review how replay state is shared across servers and how long it is retained. A check that works on one process may fail when requests reach different instances. Use synthetic transactions for testing and avoid collecting real bearer credentials. The goal is a clear relationship between authenticated messages, current protocol context, and allowed business effects.
Keep exploring
References & further reading
Original explanations, with primary references for deeper study.
NIST: Cryptographic Standards and Guidelines