Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
Replay attack
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
{{Short description|Network attack in which valid data transmission is repeated or delayed}} A '''replay attack''' (also known as a '''repeat attack''' or '''playback attack''') is a form of [[Computer network|network]]<ref name=":1" /> attack in which valid data transmission is maliciously or fraudulently repeated or delayed.<ref name=":1">{{Cite journal|last1=El Abbadi|first1=Reda|last2=Jamouli|first2=Hicham|date=2021-01-25|editor-last=Moreno-Valenzuela|editor-first=Javier|title=Takagi–Sugeno Fuzzy Control for a Nonlinear Networked System Exposed to a Replay Attack|journal=Mathematical Problems in Engineering|language=en|volume=2021|pages=1–13|doi=10.1155/2021/6618105|issn=1563-5147|doi-access=free}}</ref> This is carried out either by the originator or by an [[Adversary (cryptography)|adversary]] who intercepts the data and re-transmits it, possibly as part of a [[spoofing attack]] by [[IP packet (disambiguation)|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."<ref name=":0">{{cite web|last1=Malladi|first1=Sreekanth|title=On Preventing Replay Attacks on Security Protocols|url=https://apps.dtic.mil/dtic/tr/fulltext/u2/a462295.pdf|archive-url=https://web.archive.org/web/20220120144617/https://apps.dtic.mil/dtic/tr/fulltext/u2/a462295.pdf|url-status=live|archive-date=January 20, 2022|website=oai.dtic.mil}}</ref> ==Example== [[File:Replay attack on hash.svg|thumb|300px|Illustration of a replay attack. Alice (A) sends her hashed password to Bob (B). Eve (E) sniffs the hash and replays it.]] Suppose [[characters in cryptography|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 [[hash function|hashing]], or even [[Salt (cryptography)|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.<ref name=":0" /> ==Prevention and countermeasures== Replay attacks can be prevented by tagging each [[Encryption|encrypted]] component with a [[session ID]] and a component number.<ref name=":0" /> 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.<ref name=":0" /> [[Session ID]]s, 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. # Bob sends a one-time token to Alice, which Alice uses to transform the password and send the result to Bob. For example, she would use the token to compute a hash function of the session token and append it to the password to be used. # On his side Bob performs the same computation with the session token. # If and only if both Alice’s and Bob’s values match, the login is successful. # Now suppose an attacker Eve has captured this value and tries to use it on another session. Bob would send a different session token, and when Eve replies with her captured value it will be different from Bob's computation so he will know it is not Alice. Session tokens should be chosen by a random process (usually, [[Pseudorandomness|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]]. [[One-time password]]s are similar to session tokens in that the password expires after it has been used or after a very short amount of time. They can be used to authenticate individual transactions in addition to sessions. These can also be used during the authentication process to help establish trust between the two parties that are communicating with each other. Bob can also send [[Cryptographic nonce|nonce]]s but should then include a [[message authentication code]] (MAC), which Alice should check. [[Timestamping (computing)|Timestamping]] is another way of preventing a replay attack.<ref>{{Cite journal|last1=Ferrara|first1=Pietro|last2=Mandal|first2=Amit Kr|last3=Cortesi|first3=Agostino|last4=Spoto|first4=Fausto|date=2020-11-24|title=Static analysis for discovering IoT vulnerabilities|journal=International Journal on Software Tools for Technology Transfer|language=en|volume=23|issue=1|pages=71–88|doi=10.1007/s10009-020-00592-x|issn=1433-2779|doi-access=free|hdl=10278/3734701|hdl-access=free}}</ref> [[Synchronization]] should be achieved using a secure protocol. For example, Bob periodically broadcasts the time on his clock together with a MAC. When Alice wants to send Bob a message, she includes her best estimate of the time on his clock in her message, which is also authenticated. Bob only accepts messages for which the timestamp is within a reasonable tolerance. Timestamps are also implemented during [[mutual authentication]], when both Bob and Alice authenticate each other with unique session IDs, in order to prevent the replay attacks.<ref>Dewanta, Favian and Masahiro Mambo. 2019. “A Mutual Authentication Scheme for Secure Fog Computing Service Handover in Vehicular Network Environment.” IEEE Access 7:103095–114.</ref> The advantages of this scheme are that Bob does not need to generate (pseudo-) random numbers and that Alice doesn't need to ask Bob for a random number. In networks that are [[Unidirectional network|unidirectional]] or near unidirectional, it can be an advantage. The trade-off being that replay attacks, if they are performed quickly enough, i.e. within that 'reasonable' limit, could succeed. ===Kerberos protocol prevention=== The [[Kerberos (protocol)|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.<ref>{{Cite web|url=https://redmondmag.com/articles/2012/02/01/understanding-the-essentials-of-the-kerberos-protocol.aspx|title=Kerberos Authentication 101: Understanding the Essentials of the Kerberos Security Protocol|last=Olsen|first=Geir|date=1 February 2012|website=Redmond Magazine|language=en|access-date=2017-06-13}}</ref> 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 [[Key (cryptography)|keys]] between the different servers. The [[encryption]] that is provided by these three keys help aid in preventing replay attacks.<ref>{{Cite journal|last1=Dua|first1=Gagan|title=Replay Attack Prevention in Kerberos Authentication Protocol Using Triple Password|journal=International Journal of Computer Networks & Communications|volume=5|issue=2|pages=59–70|arxiv=1304.3550|year=2013|doi=10.5121/ijcnc.2013.5205|s2cid=9715110}}</ref> ===Secure routing in ad hoc networks=== [[Wireless ad hoc network]]s are also susceptible to replay attacks. In this case, the authentication system can be improved and made stronger by extending the [[Ad hoc On-Demand Distance Vector Routing|AODV]] protocol. This method of improving the security of Ad Hoc networks increases the security of the network with a small amount of overhead.<ref>{{cite book|last1=Zhen|first1=Jane|title=Ad-Hoc, Mobile, and Wireless Networks|volume=2865|pages=140–150|doi=10.1007/978-3-540-39611-6_13|chapter=Preventing Replay Attacks for Secure Routing in Ad Hoc Networks|series=Lecture Notes in Computer Science|year=2003|isbn=978-3-540-20260-8}}</ref> If there were to be extensive [[Overhead (computing)|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. === Challenge-Handshake Authentication Protocol === Authentication and sign-on by clients using [[Point-to-Point Protocol]] (PPP) are susceptible to replay attacks when using [[Password Authentication Protocol]] (PAP) to validate their identity, as the authenticating client sends its username and password in "[[Plaintext|normal text]]", and the authenticating server then sends its acknowledgment in response to this; an intercepting client is therefore, free to read transmitted data and impersonate each of the client and server to the other, as well as being able to then store client credentials for later impersonation to the server. [[Challenge-Handshake Authentication Protocol]] (CHAP) secures against this sort of replay attack during the authentication phase by instead using a "challenge" message from the authenticator that the client responds with a hash-computed value based on a [[shared secret]] (e.g. the client's password), which the authenticator compares with its own calculation of the challenge and shared secret to authenticate the client. By relying on a shared secret that has not itself been transmitted, as well as other features such as authenticator-controlled repetition of challenges, and changing identifier and challenge values, CHAP provides limited protection against replay attacks.<ref>{{Cite journal|url=https://tools.ietf.org/html/rfc1994|title=RFC 1994 – PPP Challenge Handshake Authentication Protocol (CHAP)|last=Simpson|first=William Allen|website=tools.ietf.org|year=1996 |doi=10.17487/RFC1994 |language=en|access-date=2018-09-12|url-access=subscription}}</ref> ==Real-world examples of replay attack susceptibility== There are several real-world examples of how replay attacks have been used and how the issues were detected and fixed in order to prevent further attacks. ===Remote keyless-entry system for vehicles=== Many vehicles on the road use a [[remote keyless system]], or key fob, for the convenience of the user. Modern systems are hardened against simple replay attacks but are vulnerable to buffered replay attacks. This attack is performed by placing a device that can receive and transmit [[Radio wave|radio waves]] within range of the target vehicle. The transmitter will attempt to jam any RF vehicle unlock signal while receiving it and placing it in a buffer for later use. Upon further attempts to unlock the vehicle, the transmitter will jam the new signal, buffer it, and playback an old one, creating a rolling buffer that is one step ahead of the vehicle. At a later time, the attacker may use this buffered code to unlock the vehicle.<ref>{{cite journal|last1=Beek|first1=S. van de|last2=Leferink|first2=F.|title=Vulnerability of Remote Keyless-Entry Systems Against Pulsed Electromagnetic Interference and Possible Improvements|journal=IEEE Transactions on Electromagnetic Compatibility|volume=58|issue=4|pages=1259–1265|doi=10.1109/TEMC.2016.2570303|date=1 August 2016|s2cid=39429975|url=https://research.utwente.nl/en/publications/71214bed-b914-4937-8092-9271b64cc7d4 }}</ref><ref>{{cite web|last1=Francillon|first1=Aurelien|title=Attacks on Passive Keyless Entry and Start Systems in Modern Cars|url=https://eprint.iacr.org/2010/332.pdf|website=eprint.iacr.org/|access-date=8 December 2016}}</ref> ===Text-dependent speaker verification=== Various devices use [[speaker recognition]] to verify the identity of a speaker. In text-dependent systems, an attacker can record the target individual’s speech that was correctly verified by the system, then play the recording again to be verified by the system. A counter-measure was devised using spectral bitmaps from the stored speech of verified users. Replayed speech has a different pattern in this scenario and will then be rejected by the system.<ref>{{cite book|last1=Wu|first1=Z.|title=Signal and Information Processing Association Annual Summit and Conference (APSIPA), 2014 Asia-Pacific|last2=Gao|first2=S.|last3=Cling|first3=E. S.|last4=Li|first4=H.|pages=1–5|doi=10.1109/APSIPA.2014.7041636|date=1 December 2014|isbn=978-6-1636-1823-8|s2cid=10057260}}</ref> ===Replay attacks on IoT devices=== In the realm of smart home environments, [[Internet of things]] (IoT) devices are increasingly vulnerable to replay attacks, where an adversary intercepts and replays legitimate communication signals between an IoT device and its companion app. These attacks can compromise a wide array of devices, including smart plugs, security cameras, and even household appliances. A recent study<ref>{{Cite conference | author = Lazzaro, Sara; De Angelis, Vincenzo; Mandalari, Anna Maria; Buccafurri, Francesco | title = Is Your Kettle Smarter Than a Hacker? A Scalable Tool for Assessing Replay Attack Vulnerabilities on Consumer IoT Devices | book-title = 2024 IEEE International Conference on Pervasive Computing and Communications (PerCom) | year = 2024 | pages = 114–124 | doi = 10.1109/PerCom59722.2024.10494466| arxiv = 2401.12184 }}</ref> demonstrated that a substantial portion of consumer IoT devices are prone to replay attacks. Researchers found that 75% of tested devices supporting local connectivity were vulnerable to such attacks. These vulnerabilities allow attackers to mimic legitimate commands, potentially enabling unauthorized actions such as turning on a smart kettle, unlocking doors, or manipulating security systems. Such breaches pose significant safety, security, and privacy risks, as malicious actors can gain control over critical home systems. ===In popular culture=== In the folk tale ''[[Ali Baba and the Forty Thieves]]'', the thieves' captain used the passphrase "Open, Sesame" to open the door to their loot depot. This was overheard by Ali Baba, who later reused the passphrase to get access and collect as much of the loot as he could carry.<ref>[http://www.bartleby.com/16/905.html ''Ali Baba and the Forty Thieves''] (e-text at Bartleby.com)</ref> ==See also== * [[Denial-of-service attack]] * [[Digest access authentication]] * [[Man-in-the-middle attack]] * [[Pre-play attack]] * [[Relay attack]] * [[Session replay]] * [[Telephone tapping]] ==References== {{Reflist}} {{DEFAULTSORT:Replay Attack}} [[Category:Cryptographic attacks]]
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)
Pages transcluded onto the current version of this page
(
help
)
:
Template:Cite book
(
edit
)
Template:Cite conference
(
edit
)
Template:Cite journal
(
edit
)
Template:Cite web
(
edit
)
Template:Reflist
(
edit
)
Template:Short description
(
edit
)