Replay Attacks Glossary

An attack where the attacker captures legitimate network communication — authentication credentials, session tokens, or transaction data — and retransmits that data later to impersonate the original sender. The replayed data was genuine when first transmitted; the attack exploits systems that cannot distinguish a fresh request from a retransmitted one. The attacker does not need to remain in the communication path during the replay — only during the initial capture. Prevented by encryption (denies capture), salting (makes each credential single-use), and session expiry.

A replay attack variant targeting authentication systems that transmit password hashes rather than plaintext passwords. Instead of cracking the hash to recover the plaintext password, the attacker captures the username and password hash during a legitimate authentication, then retransmits those exact values to authenticate as the victim. The server receives a valid username/hash pair and grants access. The plaintext password is never needed. Mitigated by salted authentication (each hash includes a unique nonce so previously captured hashes are rejected) and encryption of the authentication exchange.

A fixed-length cryptographic value derived from a password using a one-way hash function (e.g., NTLM, bcrypt, SHA-256). Hashing is intentionally irreversible — you cannot reliably derive the original password from the hash. Authentication systems store and transmit hashes rather than plaintext passwords for this reason. However, the hash itself is a functional substitute for the password in systems that accept it directly: if the hash is what the server checks, then possessing the hash grants the same access as possessing the password. Pass-the-hash exploits this property.

The practice of adding a unique, random value (the "salt") to a password before hashing it, so that the same password produces a different hash each time. In the context of replay attack defense: if each authentication uses a fresh salt, every login generates a different hash even for the same password. The server keeps track of used salt/hash combinations and rejects any previously seen hash, making replay attacks fail — a captured hash from a prior session cannot be replayed because the server won't accept the same hash twice. Also prevents rainbow table attacks on stored passwords.

A unique identifier assigned by a web server after successful user authentication. Stored in a browser cookie, the session ID is transmitted with every subsequent HTTP/HTTPS request to that server, allowing the server to recognize the request as coming from an already-authenticated user without requiring repeated login credentials. If an attacker captures a valid session ID, they can impersonate the authenticated user for any request — bypassing authentication entirely. Session IDs should be long, random, transmitted only over HTTPS, and expire after a defined period of inactivity.

An attack where an attacker steals a valid session ID from network traffic or a browser cookie and uses it to impersonate the authenticated user. Because the session ID represents a completed authentication, the server accepts the attacker's requests as legitimate — the original password and any multi-factor authentication is already in the session's past. The attacker needs only the session token, not the credentials that created the session. Called "sidejacking" when the session ID is captured from network traffic (e.g., on a shared Wi-Fi network) rather than through a direct compromise of the victim's device.

A small file stored on a user's computer by the web browser, containing data set by websites to maintain state across HTTP requests. Cookies store tracking information, personalization preferences, and — critically — session IDs. Cookies are not executable programs; they contain data, not code. However, a cookie containing a valid session ID is a functional authentication credential for whatever session it represents. Attackers target cookies to steal session IDs through network capture (if transmitted over HTTP), XSS injection, or physical access to the device. Protected by HTTPOnly and Secure flags, plus HTTPS.

A Firefox browser extension released in 2010 that automated session cookie capture and replay against users on the same open Wi-Fi network. It displayed a list of nearby users logged into websites that transmitted session cookies over unencrypted HTTP, and allowed one-click hijacking of those sessions. Firesheep required no technical skill and worked against major sites including Facebook and Twitter. Its release made the abstract session hijacking threat immediately understandable and directly accelerated the industry migration to HTTPS-by-default. The underlying technique — session cookie capture over unencrypted HTTP — remains valid; Firesheep simply automated it for a mass audience.

A vulnerability where an attacker injects malicious JavaScript into a web page that is then executed in other users' browsers. In the context of replay attacks, XSS is used to steal session cookies: an injected script running in the victim's browser can read the session cookie value (unless protected by the HTTPOnly flag) and transmit it to an attacker-controlled server. XSS bypasses network-layer defenses like HTTPS because the attack runs inside the legitimate browser session. Protected by Content Security Policy (CSP), input sanitization, and the HTTPOnly cookie flag.

A cookie attribute that prevents JavaScript from reading a cookie's value — the cookie is only accessible to the browser's HTTP request mechanism, not to scripts running on the page. The HTTPOnly flag is the primary defense against XSS-based session cookie theft: even if an attacker injects a script into the page, the script cannot read session cookies marked HTTPOnly. The flag is set by the server when issuing the cookie. Does not prevent the cookie from being transmitted over the network — only prevents script-based reading of its value.

A cookie attribute that instructs the browser to only transmit the cookie over HTTPS connections, never over unencrypted HTTP. Prevents session cookies from being accidentally exposed if a user visits the HTTP version of a site or if a mixed-content page loads some resources over HTTP. Works in combination with HTTPOnly to protect session IDs: HTTPOnly prevents script access; Secure prevents transmission over unencrypted channels. Both flags should be set on all session cookies as a baseline security measure.

A hardware device installed in-line on a network cable or connection point that passively copies all traffic passing through it to a monitoring port. Network taps are used legitimately for network monitoring and forensics, and maliciously by attackers to capture authentication data and session tokens for replay attacks. Unlike software-based capture methods, hardware taps are difficult to detect (they produce no network traffic themselves) and can capture traffic at full line rate without dropping frames. Physical access to the network cabling or equipment is required to install one.