What Is A Replay Attack, And How Is It Different from Idempotency Issues

A replay attack works because a captured message already carries every proof of authenticity the server checks — a valid signature, a live session token, an authenticated envelope — so re-sending the identical bytes re-passes every one of those checks, and the server, having no way to tell "this is the second time I've seen this" from "this is a new request," performs the action again.

An idempotency issue produces the same visible symptom — one intent, two executions — but the cause is honest: a slow response, a double-click, or a client timeout-and-retry resends a request nobody meant to duplicate. The distinction is not the symptom; it is intent plus what defense stops it. Replays are defeated by freshness (each request may be accepted at most once, within a short window); accidental duplicates are defeated by execution de-duplication (remember the first result and return it again). This page separates the two mechanisms cleanly, traces both with real values, and shows when each defense — and each alternative — is the right call.

Two mechanisms, side by side

Malicious replay. An attacker captures a legitimate message and re-sends it unchanged to repeat its effect. A common misconception is that this requires a full man-in-the-middle position. It does not: replay needs only passive capture plus the ability to send to the server — sniffing an unencrypted or metadata-leaking channel, reading a logged request, or grabbing a token from a browser is enough. A true MITM (who can also modify traffic in flight) is a strictly stronger, and rarer, attacker. Replay is dangerous precisely because the weaker, passive attacker can pull it off. The defense is freshness: bind each request to a one-time nonce and a timestamp, cover both with a signature, and reject anything stale or previously seen.

Accidental idempotency issue. No attacker. A retry, a refresh, or an at-least-once message queue delivers the same intent twice. The defense is an idempotency key: the client attaches a unique id per intent, the server stores the result of the first execution against that key, and any later request with the same key gets the stored result replayed back instead of a second side effect.

They overlap at one point: an attacker who replays a request against a non-idempotent endpoint gets a real duplicate side effect — the accidental-duplication bug becomes an exploit. This is why idempotency keys blunt replays too, but note the asymmetry: an idempotency key stops a duplicate side effect; it does not stop an attacker from replaying to read back a stored response, nor does it authenticate the caller. Freshness + signatures do that. The two defenses are complementary, not substitutes.

Worked trace: the freshness gate

A payment client signs each request over its timestamp, a random nonce, and the body. The server keeps a nonce cache whose TTL equals its acceptance window (300 s). Watch what happens to Alice's real request and to Eve's two replay attempts.

The elegant part: because the nonce cache TTL equals the freshness window, a fresh replay is caught by the nonce check (step 3) and a slow replay is caught by the timestamp check (step 2). The server never has to remember nonces forever — the timestamp bounds how long any single nonce could still matter. Signature alone would not stop the 60 s replay: the bytes are byte-identical, so the signature is still valid. Freshness, not the signature, is what defeats replay.

The two defenses in code

Freshness gate (stops malicious replay) — signature is necessary but not sufficient; the nonce + timestamp are what add "at most once":

def handle(req):
    ts    = req.headers["X-Timestamp"]   # unix seconds
    nonce = req.headers["X-Nonce"]       # 128-bit random, per request
    sig   = req.headers["X-Signature"]

    # 1. Signature must cover ts + nonce + body (else attacker edits ts freely)
    expected = hmac_sha256(secret, ts + nonce + req.body)
    if not constant_time_eq(sig, expected):
        return 401  # forged or tampered

    # 2. Freshness window: an old capture is useless
    if abs(now() - int(ts)) > 300:
        return 401  # stale (or clock skew)

    # 3. One-time use: atomic "add if absent" over a TTL = the window
    if not nonce_cache.add_if_absent(nonce, ttl=300):
        return 409  # replay: this nonce was already accepted

    return do_work(req)

Idempotency store (stops accidental duplicates) — the naive version has a race; the correct version reserves the key atomically before the side effect:

# WRONG: check-then-act. Two concurrent double-clicks both see no row,
# both fall through, and charge_card runs twice.
def create_payment_naive(req):
    key = req.headers["Idempotency-Key"]
    if store.get(key):                 # both requests: None
        return store.get(key).response
    resp = charge_card(req.body)       # runs TWICE under a race
    store.put(key, response=resp)
    return resp

# CORRECT: atomic insert reserves the key first (INSERT ... ON CONFLICT).
def create_payment(req):
    key = req.headers["Idempotency-Key"]  # client-generated UUID per intent
    if not store.insert_if_absent(key, state="in_flight"):
        row = store.get(key)
        if row.state == "completed":
            return row.response          # replay the stored result, no re-charge
        return 409                       # concurrent duplicate still running
    resp = charge_card(req.body)         # the real, non-idempotent effect
    store.update(key, state="completed", response=resp)
    return resp

Why the naive version is wrong: get then put is a read-modify-write with a gap. Two duplicate requests arriving within that gap both read "absent" and both proceed to charge_card — the exact double-charge the key was supposed to prevent. The fix is a single atomic operation (insert_if_absent / INSERT … ON CONFLICT DO NOTHING / SETNX) that lets exactly one request win the key before any side effect runs. This is Stripe's model: clients send an Idempotency-Key, the first request's result is stored and replayed for 24 h.

Pitfalls

• Signing the body but not the timestamp. If the signature doesn't cover ts, an attacker rewrites the timestamp to "now" and sails through the freshness window with an old, still-signed body. Sign everything that the checks depend on.
• Nonce cache TTL shorter than the freshness window. If nonces are evicted at 60 s but you accept a 300 s window, a replay at 90 s finds the nonce gone and the timestamp still fresh — it gets through. TTL must be ≥ the window.
• Clock skew set too tight. A 5 s window looks secure but rejects legitimate clients whose clocks drift or who sit behind slow mobile links. Too loose (say, an hour) gives replays a huge runway. 30–300 s with NTP-synced servers is the usual balance.
• Idempotency key derived from payload, not intent. Hashing the request body as the key means two genuinely distinct $100 payments a second apart collide and the second silently returns the first's result. The key must identify the intent (a client-generated UUID), not the bytes.
• Same key, different body — silently replaying the wrong result. Store a fingerprint (a hash of the normalized payload) alongside the key. If a later request reuses the key but the body differs, that is a 409, not a cache hit — a key collision (accidental client bug, or an attacker probing) otherwise masks a real mismatch or leaks another caller's stored response. And namespace keys per authenticated caller, so one tenant can never present another tenant's key and read back its result.
• Caching failures under the idempotency key. If you store a transient 500 against the key, the client's legitimate retry gets the cached failure forever. Only cache terminal outcomes; let retries re-drive in-flight or failed states.
• Assuming idempotency is a security control. It de-duplicates side effects; it does not authenticate. An attacker replaying a signed "read my balance" request still reads the balance. Freshness + auth stop the replay; idempotency only stops the duplicate write.

When to use which — and the trade-offs

These are three defenses against "the same request twice." Choosing among them is a judgment about who is repeating the request and what you must prevent.

Nonce cache (reject-if-seen)

Choose it when the threat is a malicious replay and you need a hard "exactly once" over a short window — payment authorizations, auth handshakes, signed webhooks. Gain: true one-time acceptance. Cost: shared, low-latency state (Redis) on the hot path, and its memory grows with request rate × TTL; every request pays a network round-trip to the cache.

Timestamp window alone (no nonce)

Choose it when you want cheap, stateless replay resistance and can tolerate replays within the window. Gain: zero shared state — each node checks the clock independently. Cost: it only shrinks the attack window, it doesn't close it; anything inside the window replays freely. Prefer the nonce cache when a single duplicate is unacceptable (money); prefer timestamp-only when the operation is naturally idempotent and you just want to bound staleness.

Idempotency key (store-and-replay)

Choose it when the repeats are honest — retries, at-least-once queues, double-clicks — and you need the duplicate to be a no-op that returns the original result. Gain: safe retries, better UX, and it happens to blunt replays too. Cost: durable per-key storage with a retention policy, careful state machine (in-flight vs completed vs failed), and it authenticates nothing.

The senior call: for a money-moving endpoint on an open network, you layer them — TLS + a signature (authenticate), a nonce + timestamp (stop replay), and an idempotency key (make honest retries safe). They defend different failure modes; picking one and calling it done is the mistake. If you must pick one for an internal, already-authenticated service whose real problem is retry storms, the idempotency key earns its keep; if the problem is an untrusted network and forged replays, start with nonce + timestamp + signature.

Takeaways

• Replay works because identical bytes re-pass every check; it needs only passive capture and the ability to send — not a full man-in-the-middle. The signature is still valid on a replay, so freshness (nonce + timestamp), not the signature, is what stops it.
• An idempotency issue is the same duplicate-execution symptom from honest retries; it's defeated by storing the first result and replaying it — reserved with an atomic insert, or two concurrent duplicates both fire.
• They overlap only where an attacker replays a non-idempotent endpoint. Idempotency de-duplicates side effects but authenticates nothing; freshness + signatures are the security control.
• On an open, money-moving path, layer all three: TLS + signature, nonce + timestamp, idempotency key. Each covers a failure mode the others don't.

Sources: RFC 2617 / RFC 7616 (HTTP Digest nonces and replay), OWASP guidance on replay prevention and cryptographic freshness, the Stripe API reference on idempotent requests (Idempotency-Key semantics and 24-hour result retention), and Kleppmann, Designing Data-Intensive Applications (at-least-once delivery, deduplication, and exactly-once processing). Re-authored and deepened for this guide.