A replay attack (also known as a repeat attack or playback attack) is a form of network attack in which valid data transmission is maliciously or fraudulently repeated or delayed. This is carried out either by the originator or by an adversary who intercepts the data and re-transmits it, possibly as part of a spoofing attack by IP packet substitution. This is one of the lower-tier versions of a man-in-the-middle attack. Replay attacks are usually passive in nature.

Another way of describing such an attack is: "an attack on a security protocol using a replay of messages from a different context into the intended (or original and expected) context, thereby fooling the honest participant(s) into thinking they have successfully completed the protocol run."

Suppose Alice wants to prove her identity to Bob. Bob requests her password as proof of identity, which Alice dutifully provides (possibly after some transformation like hashing, or even salting, the password); meanwhile, Eve is eavesdropping on the conversation and keeps the password (or the hash). After the interchange is over, Eve (acting as Alice) connects to Bob; when asked for proof of identity, Eve sends Alice's password (or hash) read from the last session which Bob accepts, thus granting Eve access.

Replay attacks can be prevented by tagging each encrypted component with a session ID and a component number. This combination of solutions does not use anything that is interdependent on one another. Due to the fact that there is no interdependency, there are fewer vulnerabilities. This works because a unique, random session ID is created for each run of the program; thus, a previous run becomes more difficult to replicate. In this case, an attacker would be unable to perform the replay because on a new run the session ID would have changed.

Session IDs, also known as session tokens, are one mechanism that can be used to help avoid replay attacks. The way of generating a session ID works as follows.

Session tokens should be chosen by a random process (usually, pseudorandom processes are used). Otherwise, Eve may be able to pose as Bob, presenting some predicted future token, and convince Alice to use that token in her transformation. Eve can then replay her reply at a later time (when the previously predicted token is actually presented by Bob), and Bob will accept the authentication.

The Kerberos authentication protocol includes some countermeasures. In the classic case of a replay attack, a message is captured by an adversary and then replayed at a later date in order to produce an effect. For example, if a banking scheme were to be vulnerable to this attack, a message which results in the transfer of funds could be replayed over and over to transfer more funds than originally intended.

However, the Kerberos protocol, as implemented in Microsoft Windows Active Directory, includes the use of a scheme involving time stamps to severely limit the effectiveness of replay attacks. Messages which are past the "time to live (TTL)" are considered old and are discarded.

There have been improvements proposed, including the use of a triple password scheme. These three passwords are used with the authentication server, ticket-granting server, and TGS. These servers use the passwords to encrypt messages with secret keys between the different servers. The encryption that is provided by these three keys help aid in preventing replay attacks.

Wireless ad hoc networks are also susceptible to replay attacks. In this case, the authentication system can be improved and made stronger by extending the AODV protocol. This method of improving the security of Ad Hoc networks increases the security of the network with a small amount of overhead. If there were to be extensive overhead then the network would run the risk of becoming slower and its performance would decrease. By keeping a relatively low overhead, the network can maintain better performance while still improving the security.