Replay Attacks: Why Stolen Tokens Should Die in 200 Milliseconds

The attacker captures a valid authentication token. They don’t need to crack it, decode it, or understand it. They just re-transmit it — exactly as captured — to the server. The server sees a valid token and grants access.

This is a replay attack. It is one of the oldest attacks in computer security, and it works because most authentication systems treat tokens as timeless proof of identity. If the token is valid, access is granted. No questions asked about when, where, or how the token was obtained.

How replay attacks work

A replay attack has three steps:

1. Capture: The attacker intercepts a valid authentication token. This can happen via network interception (evil twin, ARP poisoning), malware (browser cookie theft), or server-side data breach.
2. Store: The token is saved. It doesn’t matter if the original session ends. The token persists.
3. Replay: The attacker sends the captured token to the server at any later time. The server validates it and grants access.

The beauty of a replay attack (from the attacker’s perspective) is its simplicity. No cryptographic skill required. No password cracking. No vulnerability exploitation. Just capture and retransmit.

Why traditional token expiry is too slow

The standard defense against replay attacks is token expiration. Give the token a lifetime. After it expires, it can’t be replayed.

The problem is the lifetime:

• OAuth access tokens: Typically 1 hour
• JWT tokens: Commonly 15 minutes to 24 hours
• Session cookies: Often 30 days (“remember me”)
• API keys: Frequently never expire
• Refresh tokens: 30 to 90 days, sometimes indefinite

An attacker who captures a token with a 1-hour lifetime has 1 hour of unrestricted access. An attacker who captures a 30-day session cookie has 30 days. The token lifetime is the attack window.

Why not make tokens expire faster? Because traditional systems can’t rotate tokens fast enough without breaking the user experience. Every token rotation requires a round trip to the authentication server. At high rotation speeds, the network overhead and latency become unacceptable.

Token lifetime is a tradeoff between security and usability. Short tokens are more secure but create more friction. Long tokens are more usable but create larger attack windows. The entire industry is stuck in this tradeoff. ZK Proven eliminates it.

Nonces: the partial solution

Cryptographic nonces (numbers used once) are designed to prevent replay attacks. Each request includes a unique nonce. The server tracks which nonces have been used and rejects duplicates.

Nonces work in theory but have practical problems:

• Server-side state: The server must store every used nonce for the token’s lifetime. For high-volume APIs, this creates enormous storage and lookup overhead.
• Clock synchronization: Time-based nonces require synchronized clocks between client and server. Clock drift causes legitimate requests to be rejected.
• Distributed systems: In multi-server environments, the nonce database must be replicated across all servers in real time. This adds latency and complexity.
• Window attacks: Nonce systems typically accept nonces within a time window to account for clock drift. This window is the replay attack surface.

How ZK Proven eliminates replay attacks

ZK Proven doesn’t extend traditional token expiry. It replaces the entire model with ephemeral CRYSTALS-Dilithium keys that rotate every 200 milliseconds.

Dilithium temporal binding

Every 200ms proof interval generates a fresh Dilithium keypair. The proof submitted to the server is signed with this interval’s private key. The signature includes a temporal binding — a cryptographic commitment to the current monotonic timestamp.

A replayed proof has a timestamp from a previous interval. The temporal binding doesn’t match the current time window. The server rejects it. Not because of a nonce database lookup, but because the cryptographic proof itself is time-bound.

200ms key expiry

At the end of each 200ms interval, the private key is cryptographically destroyed. It is zeroized in memory. It cannot be recovered. Even if an attacker captures the proof, the key that signed it no longer exists.

Compare this window to traditional token lifetimes:

Nullifier chain validation

Every proof interval generates a nullifier — a unique value derived from the session state. The nullifier chain is sequential: nullifier N depends on nullifier N-1. A replayed proof from a previous interval presents a nullifier that breaks the chain. The server detects the discontinuity immediately.

This is stronger than nonce-based protection because the nullifier chain is self-validating. The server doesn’t need to store used nullifiers. It only needs to track the current position in the chain. If the presented nullifier doesn’t follow from the current position, it’s a replay.

Forward and backward secrecy

Each 200ms interval uses a fresh CRYSTALS-Kyber key exchange to ratchet the session key. Compromise of one interval’s key material reveals nothing about any other interval. This provides both forward secrecy (future intervals are protected) and backward secrecy (past intervals are protected).

A captured proof from interval T is useless at T+1 because the entire cryptographic context has changed. Different keys. Different nullifier. Different temporal binding. Different session key.

Replay attacks in the real world

Kerberos Golden Ticket

The Golden Ticket attack against Active Directory is fundamentally a replay attack. The attacker forges a Kerberos ticket-granting ticket (TGT) and replays it indefinitely — because Kerberos TGTs have a 10-hour default lifetime and Golden Tickets can be forged with arbitrary lifetimes.

OAuth token theft

In 2024, a major SaaS provider disclosed that attackers stole OAuth tokens through a compromised third-party integration. The tokens had 24-hour lifetimes. The attacker had 24 hours of access to customer data before the tokens expired. With ZK Proven, that window would have been 200 milliseconds.

API key replay

API keys that never expire are permanent replay targets. A leaked API key in a public GitHub repository (which happens thousands of times per day, according to GitGuardian) provides indefinite access until someone manually revokes it. The median time to revocation: 5 days.

The math of 200ms

An attacker who captures a ZK Proven proof has 200 milliseconds to:

1. Receive the captured proof from the network interception point
2. Parse the proof to extract the authentication material
3. Construct a new request using the captured material
4. Transmit the request to the target server
5. Have the server process the request before the interval expires

Network latency alone (capture point to attacker to server) typically exceeds 200ms. The attack window is effectively zero for any attacker who isn’t colocated with both the victim and the server.

And even if the timing worked, the nullifier chain and Dilithium temporal binding provide independent rejection mechanisms. All three must be defeated simultaneously.

Tokens should be disposable

The authentication industry treats tokens as valuable artifacts that need to be protected. ZK Proven treats them as disposable proofs that need to be destroyed. Generate. Verify. Destroy. Every 200 milliseconds. The concept of “token theft” becomes meaningless when the token is already dead by the time the attacker tries to use it.