Cybersecurity glossary
What is a Replay Attack?
Learn what a replay attack is, how captured protocol messages or credentials are reused, where TLS and auth protocols stop replays, and which nonces, timestamps, and binding defenses work.
Definition
A replay attack is a network or application attack in which an adversary captures a valid protocol message, token, or encrypted record and later retransmits it to trick a receiver into accepting the old message as a fresh, legitimate action—often without needing to decrypt or forge new cryptography.
Why replay attacks matter
Cryptography often proves that a message was produced by someone with the right key. It does not automatically prove that the message is happening now or happening only once. A replay attack exploits that gap: capture something valid, store it, and present it again when it still looks acceptable.
Replays undermine payments, unlock commands, authentication handshakes, OTP submissions, and signed API requests. They are especially dangerous because defenders monitoring for “invalid signatures” may see only valid ones—just duplicated.
What a replay attack actually is
At its core, replay is unauthorized retransmission of authentic data. The captured artifact might be cleartext, ciphertext, a Kerberos ticket, a challenge response, or an HTTP request with cookies. If receivers lack freshness and uniqueness checks, cryptography alone will approve the repeat.
Capture phase
Attacker observes or steals a valid message, token, or encrypted record from network, logs, backups, or malware.
Storage phase
The artifact remains useful until expiry, rotation, or single-use enforcement invalidates it.
Replay phase
Retransmission causes the victim system to perform the original action or grant the original access again.
Why crypto may still verify
Signatures and MACs validate integrity and authenticity—not necessarily freshness—unless designed to.
How replay attacks unfold
Position to observe or steal
MITM, compromised endpoint, verbose logging, or extracted bearer tokens provide the reusable material.
Select a high-value message
Prefer actions with lasting effect: fund transfers, access grants, device unlocks, or session establishment proofs.
Wait or retransmit immediately
Some replays are instant; others wait until administrators are offline or rate limits reset.
Present the old artifact
The attacker sends the captured bytes to the honest receiver without needing to forge a new signature.
Receiver accepts if still fresh-looking
Absent nonce stores, idempotency controls, or binding, the system treats the replay as a new legitimate event.
Replay versus related auth abuses
| Property | Replay | Token replay | Session hijacking |
|---|---|---|---|
| Primary object | Any valid prior message/record | Bearer/session/assertion token | Live session identity control |
| Must decrypt? | Often no | No—possession suffices | No if cookie/token stolen |
| Typical defense | Nonces, timestamps, sequence #s | TTL, DPoP/mTLS, revocation | Secure cookies, XSS defense, MFA |
| Crypto still verifies? | Frequently yes | Signature/MAC may still verify | Session appears legitimate |
| Scope | Broad protocol concern | Identity/API specialization | Ongoing user impersonation |
Where replays show up
Challenge–response without uniqueness. If a response can be reused, capturing one login proof is enough.
Signed URLs and webhooks. Stable signatures without expiry or nonce parameters are replayable by anyone who saw the URL.
Industrial and IoT commands. “Open door” or “start motor” ciphertexts replayed on the wire cause physical effects.
TLS 0-RTT early data. TLS 1.3 permits 0-RTT for performance; applications must treat early data as replayable unless higher-layer anti-replay is in place.
Encrypted database rows or cookies. Re-submitting an old ciphertext can restore a previous authorization state if the server decrypts and trusts it again.
Defenses that establish freshness
Nonces and sequence numbers
Receivers remember used values (or accept only monotonic counters) and reject duplicates.
Tight time windows
Timestamps plus clock skew limits shrink the replay interval; combine with uniqueness, do not rely on time alone.
Request binding
Sign method, path, body hash, and audience so a captured message cannot be redirected or reordered usefully.
Single-use credentials
One-time tokens, rotating refresh chains, and idempotency keys make identical retransmission harmless or rejected.
What practitioners should do today
- Threat-model every side-effecting API for capture-and-resubmit, including webhooks and signed callbacks.
- Require nonces or idempotency keys for state-changing requests and persist them until expiry.
- Keep access tokens short-lived; revoke on logout and privilege change.
- Prefer sender-constrained tokens (DPoP, mTLS) for high-risk APIs to blunt pure bearer replay.
- Disable or carefully gate TLS 0-RTT for non-idempotent operations.
- Avoid logging full Authorization headers or signed URLs that become replay fodder.
- Use AEAD nonces correctly—nonce reuse is a different failure, but nonce tracking also supports anti-replay designs.
- Alert on duplicate message IDs, repeated webhook delivery signatures, or burst identical signed requests.
Lessons for protocol design
Replay resistance is a distinct security goal from confidentiality and integrity. Designers must ask: “If someone records this exact byte string, what happens when it returns?” If the answer is “the same privileged action,” the protocol is incomplete.
Hybrid defenses work best: short lifetimes reduce windows; unique nonces close windows; binding prevents creative reuse; monitoring catches operational mistakes when stores fail.
The practical takeaway
A replay attack reuses a previously valid message or credential so a system accepts an old action as new. Stop replays with nonces, sequence numbers, short expirations, cryptographic binding, and single-use semantics—especially for payments, sessions, and any command that should happen only once.
Related security terms
Token Replay
Application-layer specialization where stolen bearer or session tokens are reused.
Nonce
Single-use values that make captured messages invalid on retransmission.
Man-in-the-Middle (MITM)
Common vantage for capturing messages that will later be replayed.
Session Hijacking
Related outcome when replayed session material lets an attacker impersonate a user.
TLS 1.3
Includes design choices that constrain 0-RTT replay risk compared with naive early data.
Frequently asked questions
What is a replay attack in simple terms?
An attacker records a legitimate message—like a payment request or login proof—and plays the recording later so the system thinks the same action is happening again.
Do you need to break encryption to replay?
Not always. If a ciphertext or token is still considered valid when re-sent, replaying the bytes can succeed without decryption.
How do nonces stop replays?
Each fresh message includes a unique value the receiver tracks. Seeing the same nonce twice marks the message as a replay and causes rejection.
Are timestamps enough?
Timestamps limit how long a captured message remains acceptable, but without uniqueness checks an attacker can still replay inside the validity window.
Is TLS immune to replay?
Recorded full handshakes are not simply replayable as new sessions under modern TLS, but application data and especially 0-RTT early data need explicit anti-replay design. Application tokens remain separately replayable if stolen.
How is replay different from CSRF?
CSRF tricks a victim browser into sending a new authenticated request. Replay reuses a previously captured valid message or credential bytes, often from another vantage point.
What should APIs do?
Use short-lived tokens, bind requests to method/path/body hashes, require idempotency keys for side-effecting calls, and reject duplicated nonces or signatures.
References
Explore authoritative guidance and frameworks related to replay attack.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.