Replay Attacks: What They Are and Why Time-Based Tokens Exist
A replay attack is simple in concept: capture a valid authentication or authorization message, then re-submit it later to get the same access. You don't need to understand the cryptography. You don't need to crack any passwords. You just need to record a valid message and play it back.
How a Replay Attack Works
sequenceDiagram
participant ALICE as Alice (Sender)
participant EVE as Eve (Attacker)
participant BOB as Bob (Receiver)
rect rgb(30, 40, 30)
Note over ALICE,BOB: Legitimate Transaction
ALICE->>BOB: "Transfer $500 to Carol"
(digitally signed, valid auth token)
BOB->>BOB: Verify signature - VALID
BOB->>BOB: Process transfer
BOB-->>ALICE: Confirmation
end
Note over EVE: Eve captured the message
in transit (passive sniffing)
rect rgb(40, 20, 20)
Note over EVE,BOB: Replay Attack (hours later)
EVE->>BOB: Exact same message replayed
"Transfer $500 to Carol"
BOB->>BOB: Verify signature - STILL VALID
BOB->>BOB: Process transfer AGAIN
BOB-->>EVE: Confirmation
end
Note over BOB: Bob processed the same
transaction twice!
$1000 transferred total
rect rgb(30, 30, 40)
Note over ALICE,BOB: With Replay Protection
ALICE->>BOB: "Transfer $500" + nonce: 7a3f
+ timestamp: 2024-01-15T14:30:00Z
BOB->>BOB: Check nonce not seen before
BOB->>BOB: Check timestamp within 5 min
BOB->>BOB: Process transfer
Note over EVE: Replays same message
EVE->>BOB: Same message + nonce: 7a3f
BOB->>BOB: Nonce 7a3f already used - REJECT
end
Replay attack mechanics - without nonces or timestamps, a valid signed message can be replayed indefinitely because the signature never expires
- Alice sends an authentication message to Bob's server containing a credential.
- An attacker (Eve) intercepts and records the message - without decrypting it.
- Later, Eve replays the captured message to Bob's server.
- The server receives what looks like a valid authentication and grants access.
The attack works because the captured message is legitimate. The credentials are real. The signature (if any) is valid. If the server has no mechanism to detect the message has been seen before, it grants access.
Why IR Remote Control Is a Replay Attack
sequenceDiagram
participant REMOTE as TV Remote
participant IR_ENV as IR Signal
(Line of Sight)
participant TV as Television
participant BN as BLEShark Nano
rect rgb(30, 30, 30)
Note over REMOTE,TV: Normal Remote Operation
REMOTE->>IR_ENV: IR pulse sequence
(38kHz carrier, NEC protocol)
IR_ENV->>TV: Power ON command
TV->>TV: Turns on
end
rect rgb(40, 30, 30)
Note over BN,TV: IR Capture Phase
REMOTE->>IR_ENV: Volume UP command
IR_ENV->>BN: IR receiver captures
raw pulse timing
BN->>BN: Store signal in memory
Note over BN: Signal saved:
Protocol: NEC
Address: 0x04
Command: 0x02
end
rect rgb(30, 40, 30)
Note over BN,TV: IR Replay Phase
Note over BN: User triggers replay
BN->>IR_ENV: Transmit stored signal
(exact pulse timing)
IR_ENV->>TV: Volume UP command
TV->>TV: Volume increases
Note over TV: TV cannot distinguish
original from replay
end
Note over REMOTE,TV: IR remotes have NO replay
protection - pure command replay
IR remote replay attack using BLEShark Nano - IR protocols have zero replay protection, making capture-and-replay trivial
Infrared remote controls are one of the most everyday examples of replay attack vulnerability. The signal is completely deterministic - press "Volume Up" ten times in a row and the same pattern goes out every time. Any device that can capture and retransmit that IR signal works as a volume up command. The TV cannot distinguish the captured replay from the original.
The BLEShark Nano's IR receive and transmit capability is essentially an IR replay attack tool - intentionally. You capture a remote's signal using the Receive app and replay it using the Transmit app. For the TV-B-Gone feature, the device cycles through a database of known IR power codes and transmits each one.
Why Authentication Protocols Prevent Replays
Nonces
A nonce is a "number used once" - a random value generated fresh for each transaction. In challenge-response authentication, the server generates a random nonce, the client incorporates it into their response. A captured response to a previous challenge is useless because it incorporates a different nonce than the current challenge.
WPA2's 4-way handshake uses nonces. The captured handshake can't be replayed to authenticate - new handshakes use new nonces, and the session key derived from old nonces doesn't match.
Timestamps
If a message includes the current time and the receiver rejects messages older than a certain window (say 30 seconds), captured messages expire quickly. Kerberos uses timestamps and requires clock skew within 5 minutes between all parties.
TOTP: Time-Based One-Time Passwords
TOTP (RFC 6238) generates a one-time password from a shared secret key and the current time, changing every 30 seconds. The server and authenticator app both compute the same value without communicating. By the time an attacker captures a TOTP code and attempts to replay it, the 30-second window has usually closed.
Replay Attacks in WPA2 Wireless Networks
WPA2 handshake captures made by the BLEShark Nano are not usable replay credentials - they're challenge-response messages tied to specific nonces. The captured handshake is used for offline dictionary attacks against the PSK, not replayed to authenticate. WPA2-CCMP includes per-packet sequence numbers that prevent replay of data frames.
Physical Access Control Replay Vulnerabilities
RFID and NFC-based access control is a significant real-world replay attack surface. Many older 125kHz proximity card reader systems use fixed card numbers - any device that captures that ID can replay it to open the door. Modern systems use mutual authentication and rolling codes. But legacy 125kHz deployments are extremely common in existing building infrastructure.
Defense Summary
graph TD
subgraph "Replay Prevention Mechanisms"
NONCE["Nonces
(number used once)"]
TS["Timestamps
(time window validation)"]
SEQ["Sequence Numbers
(monotonic counter)"]
CHAL["Challenge-Response
(server sends random
challenge each time)"]
TOTP_N["TOTP
(time-based one-time
password)"]
end
subgraph "Where Each Is Used"
NONCE --> N1["WPA2 4-way handshake
(ANonce + SNonce)"]
NONCE --> N2["TLS handshake
(client/server random)"]
TS --> T1["Kerberos tickets
(5-min time window)"]
TS --> T2["OAuth tokens
(expiration time)"]
SEQ --> S1["TCP connections
(sequence numbers)"]
SEQ --> S2["802.11 frame counter
(CCMP replay detection)"]
CHAL --> C1["HTTP Digest auth"]
CHAL --> C2["RFID challenge-response
(modern access cards)"]
TOTP_N --> TO1["Google Authenticator
(30-second codes)"]
TOTP_N --> TO2["Hardware security keys
(FIDO2/WebAuthn)"]
end
subgraph "NO Replay Protection"
NONE["IR remotes
Older RFID cards
Basic garage openers
Unprotected 802.11
management frames"]
BN_TEST["BLEShark Nano can
test these systems"]
end
NONE --> BN_TEST
Replay prevention mechanisms across protocols - systems without these defenses (like IR remotes) remain permanently vulnerable to replay attacks
- Use challenge-response authentication with fresh nonces rather than static credentials
- Implement TOTP or FIDO2/WebAuthn for second-factor authentication
- Enforce session timeouts and token invalidation on logout
- Use protocols with built-in anti-replay (WPA2-CCMP, TLS, SSH)
- For physical IR/RF control: use rolling codes or challenge-response where access warrants it