Replay Attacks - Reusing Captured Data
About 2 min read
A replay attack is an attack technique that attempts unauthorized access by intercepting legitimate communication data and resending that same data as-is. Its distinguishing feature is that the attacker does not need to break the encryption; the attack succeeds simply by "recording and replaying" legitimately authenticated data. It is often executed in combination with a man-in-the-middle attack, and any communication can become a target, including authentication tokens, API requests, and financial transaction data. Although the principle is simple, it is a troublesome attack that cannot be prevented by encryption in transit alone without appropriate countermeasures.
How the Attack Works
Capture legitimate communication
Record the data as-is
Send identical data to the server
Server mistakes it as legitimate
The crucial point is that the attacker does not need to understand the content of the data. Even encrypted data, if resent as-is, will be processed by the server as a legitimate request. Encryption via TLS prevents eavesdropping, but it cannot prevent the reuse of data captured within a legitimate session.
The Difference from Session Hijacking
Replay attacks and session hijacking are easily confused, but their attack mechanisms differ.
- Resends past communication data
- Works even if the original session has ended
- No modification of the data is needed
- Countermeasures: nonces, timestamps
- Takes over an active session
- Effective only while the session is valid
- Requires stealing the session ID
- Countermeasures: session fixation prevention, re-authentication
Countermeasure Techniques
Countermeasures against replay attacks come down to introducing mechanisms that "make the same data unusable twice."
Why FIDO/WebAuthn Resists Replay Attacks
The FIDO/WebAuthn protocol builds resistance to replay attacks in from the design stage. Each time authentication occurs, the server generates a random challenge, and the client signs that challenge with its private key. Because the signature includes the challenge value, the origin (the connecting domain), and the authenticator counter value, resending a past signature is immediately rejected due to a mismatched challenge. It is important to harden the entire authentication flow in combination with session hijacking countermeasures and session token theft defenses.
Kerberos Ticket Expiration
The Kerberos authentication protocol, widely used in Active Directory environments, also has built-in replay attack countermeasures. The authentication ticket (TGT) is assigned an expiration period (10 hours by default), and expired tickets are rejected. Furthermore, each request includes a timestamp, and the server verifies that the time difference between server and client is within 5 minutes. This time-synchronization requirement is also why operating an NTP server is considered essential in a Kerberos environment.
Replay attacks are a classic technique, but as IoT devices and API communications increase, many systems with insufficient countermeasures still exist. Combining them with the introduction of two-factor authentication can further enhance the robustness of authentication.network security and cryptography books (Amazon) are recommended for studying protocol-level countermeasures in depth.
Was this article helpful?