Replay attack

A replay attack is a technique in which an attacker intercepts valid data passing between two parties and retransmits it in order to compromise the integrity or confidentiality of what is being communicated.

It works by getting a system to accept the same data or command twice, and to act on it the second time as if it were new.

The reason it deserves attention is that the attacker never has to break the cryptography. The captured message was legitimate; the flaw is that the receiver has no way of knowing it has already seen it.

What characterises it

Interception. The attacker captures the communication between two legitimate parties, usually as network packets.

Unauthorised resend. The captured data is sent again to the target system, generally with no modification at all. The receiver interprets it as authentic because, in a narrow sense, it is.

Impersonation. Because the replayed message carries a legitimate identity, the attacker ends up acting as one of the parties in the exchange.

Integrity and confidentiality. Depending on what the replayed message does, the consequences range from a repeated transaction to full access to a session.

What actually stops it

Encryption on its own does not, which is the point most often missed. The defences are all about making a message usable exactly once:

Nonces and sequence numbers. A value the receiver will only accept once, so a second copy is rejected on arrival.

Timestamps with a tight window. The message is only valid for a few seconds, which is how Kerberos handles it.

Short-lived, bound tokens. Session and access tokens that expire quickly, and that are bound to a channel or a client certificate through mutual TLS so a stolen copy is useless elsewhere.

Where to read more

CWE-347, Improper Verification of Cryptographic Signature: the Common Weakness Enumeration category that covers this family, with technical detail and mitigations.

Microsoft, Kerberos Protocol Extensions: how Kerberos protects against replay, including the use of public key cryptography for initial authentication (PKINIT).

A worked example

A user signs in to a web application protected by token based authentication.

After authenticating, they are issued a session token that has to accompany every subsequent request as proof of who they are.

An attacker monitoring the communication between the user and the application captures that valid session token during a legitimate request.

Without modifying it, the attacker sends it back to the application server repeatedly, on behalf of the legitimate user.

The server receives a valid session token and treats each request as authentic, granting access to protected resources.

From there the attacker can act as the user: change settings, read confidential data, or make transactions the user never authorised.

Mitigating it means token expiry, binding the token to something the attacker does not have, and rejecting anything the server has already seen.