In 1993 noemden cryptografen het "de eenvoudigste aanval die er bestaat": neem een geldig bericht, wacht even en verstuur het opnieuw. Niemand bouwt een kluis met de verwachting dat de sleutel hergebruikt zal worden.
Maar dat is precies wat er gebeurde toen Ethereum en Ethereum Classic zich splitsten: dezelfde ondertekende transactie, uitgezonden op twee blockchains, verplaatste twee keer echt geld. Geen hack, geen gestolen wachtwoord, geen phishinglink.
Een herhaalde aanval die doet wat altijd al zo is geweest: legitimiteit als wapen gebruiken.
Een replay-aanval is een type inbreuk op de netwerkbeveiliging waarbij een aanvaller geldige gegevensoverdrachten onderschept en deze op kwaadaardige wijze hergebruikt of opnieuw verzendt om een systeem te misleiden.
In tegenstelling tot aanvallen waarbij gegevens worden gewijzigd of vervalst, wordt bij een replay-aanval eerder vastgelegde informatie, zoals inloggegevens, authenticatietokens of transactieverzoeken, opnieuw verzonden om een systeem te misleiden en te laten geloven dat het een nieuwe, legitieme opdracht ontvangt.
Houd er rekening mee: Een replay-aanval (herhalingsaanval) kan plaatsvinden op dezelfde keten of tussen verschillende ketens.
Wat is het verschil tussen een Same-Chain Replay Attack en een Cross-Chain Replay Attack?
Een same-chain replay-aanval vindt plaats binnen één blockchain: dezelfde ondertekende transactie of hetzelfde bericht wordt meerdere keren naar hetzelfde netwerk verzonden.
Het nonce-mechanisme voorkomt dit bij standaard Ethereum-transacties; zodra een nonce (eenmalig gebruikt getal) is verbruikt, wordt dezelfde transactie geweigerd.
Cross-chain replay-aanvallen vinden plaats tussen twee blockchains die adresformaten en handtekeninglogica delen — meestal na een hard fork.
De nonce (het getal dat eenmalig wordt gebruikt) is hier niet relevant, omdat de twee blockchains nonces onafhankelijk van elkaar bijhouden. Een transactie met nonce 5 op Ethereum en een transactie met nonce 5 op Ethereum Classic zijn verschillende records op de verschillende systemen, maar de ondertekende transactiegegevens zijn identiek.
De chain ID van EIP-155 is de specifieke oplossing voor cross-chain replay. Voor de verificatie van smart contract-handtekeningen behandelt de domeinseparator van EIP-712 zowel varianten binnen dezelfde blockchain als varianten tussen verschillende blockchains.
Wanneer replay-aanvallen daadwerkelijk plaatsvonden: drie gedocumenteerde gevallen
Replay-aanvallen in blockchain zijn geen theoretisch concept. Ze hebben bij meerdere incidenten aantoonbare financiële verliezen veroorzaakt.
De Ethereum/Ethereum Classic-fork — 2016
Toen het Ethereum-netwerk zich na de DAO-hack opsplitste in Ethereum (ETH) en Ethereum Classic (ETC), waren alle transacties die vóór de splitsing waren ondertekend geldig op beide ketens.
De twee ketens deelden identieke adresruimtes, transactieformaten en logica voor handtekeningverificatie.
Een transactie die door een willekeurige wallet werd ondertekend, was tegelijkertijd een geldige transactie voor zowel ETH als ETC.
Beurzen die ETH- en ETC-gebruikerstegoeden beheerden, werden onmiddellijk doelwit.
Aanvallers onderschepten geldige ETH-opnametransacties en voerden deze opnieuw uit op de ETC-blockchain, waardoor ETC-tegoeden werden leeggehaald die gebruikers helemaal niet van plan waren aan te raken.
In de periode na de fork werd er meer dan 40,000 ETC van de beurzen gehaald voordat de bescherming tegen replay-aanvallen op grote schaal werd ingevoerd.
Deze gebeurtenis was de directe aanleiding voor de oprichting van EIP-155.
De Ethereum-fusie — 2022
Toen Ethereum overging van Proof of Work naar Proof of Stake (de Merge), ontstond er een afgesplitste blockchain genaamd Ethereum. PoW (ETHW) werd opgericht.
Binnen enkele dagen maakte een aanvaller misbruik van het cross-chain contract Omni Bridge, dat geen specifieke bescherming tegen herhaling van ETHW-transacties bood, en voerde transacties uit waarbij 200 ETHW van het bridge-contract werd overgemaakt.
De aanvaller gebruikte orakelprijsgegevens van het ETH-mainnet op de ETHW-blockchain, waar deze verouderd en manipuleerbaar waren, als onderdeel van de aanval.
De Optimism OP-tokendiefstal — 2022
Bij een cross-chain replay-incident is er $20 miljoen aan OP-tokens gestolen van Optimism tijdens een omstreden multisig-transactiereeks.
De aanval maakte gebruik van de kloof tussen de L1- (Ethereum) en L2-ketencontexten (Optimism), waarbij een herhaling van een specifiek ondertekend bericht op de verkeerde keten tokens zonder toestemming verplaatste.
Dit zijn geen geïsoleerde incidenten. Ze vertegenwoordigen een gedocumenteerd patroon: elke keer dat een nieuwe fork of L2-implementatie twee omgevingen creëert die adres- of handtekeningformaten delen zonder ketenspecifieke binding, bestaat er een risico op herhaling.
Denk eens terug aan de laatste keer dat er een nieuwe blockchain werd gelanceerd die hetzelfde Ethereum-adres gebruikte als jij. Heb je gecontroleerd of je bestaande ondertekende autorisaties nog geldig waren op die nieuwe blockchain? Heb je geverifieerd of het ondertekeningsschema van je wallet EIP-155 bevatte? De meeste mensen niet. En de meeste mensen hadden geen problemen. Maar degenen die wel problemen hadden, verloren echt geld, en niemand had dat verwacht.
EIP-155: De oplossing die volgde op de fork van 2016
EIP-155, geïntroduceerd door Ethereum-medeoprichter Vitalik Buterin in 2016, is specifiek ontworpen om te voorkomen dat transacties worden herhaald op afgesplitste blockchains.
De oplossing was in principe eenvoudig: voeg de unieke identificatiecode van de blockchain (chainId) toe aan elke transactiehandtekening.
Vóór EIP-155 omvatte een transactiesignatuur zes gegevensvelden: nonce, gasprijs, gaslimiet, adres van de ontvanger, waarde en gegevens.
De handtekening was geldig op elke EVM-compatibele blockchain die dezelfde verificatielogica gebruikte, omdat geen van die velden aangaf voor welke specifieke blockchain de transactie bedoeld was.
Na EIP-155 bevatten transacties drie extra velden in de hash van de handtekening: chainId en twee lege placeholder-waarden.
Een transactie ondertekend voor Ethereum-mainnet (chainId = 1) is geen geldige handtekening op Optimism (chainId = 10), Polygon (chainId = 137) of enige andere EVM-keten.
Het knooppunt dat de transactie ontvangt, controleert de chainId aan de hand van zijn eigen chainId en wijst elke afwijking af.
Deze ene wijziging heeft het aantal cross-chain replay-aanvallen voor standaardtransacties aanzienlijk verminderd.
De belangrijkste beperking: EIP-155 beschermt alleen onbewerkte Ethereum-transacties.
Het biedt geen bescherming voor handtekeningen op applicatieniveau, de ondertekende berichten die slimme contracten intern verifiëren met behulp van de ecrecover-functie.
Een contract dat off-chain handtekeningen valideert zonder de chainId te controleren, is nog steeds kwetsbaar voor replay-aanvallen, zelfs als EIP-155 volledig is geïmplementeerd op transactieniveau. Dat is waar EIP-712 in beeld komt.
De nonce — Hoe deze herhaling van dezelfde keten voorkomt
De nonce (number used once) is het mechanisme dat replay-aanvallen binnen dezelfde blockchain voorkomt. Elk Ethereum-account heeft een teller die begint bij 0 en met elke verzonden transactie met 1 wordt verhoogd.
Wanneer je een transactie indient met nonce = 5, accepteert het netwerk deze alleen als de nonce van je huidige account exact 5 is.
Zodra de transactie is verwerkt, wordt de nonce van uw account 6. Elke poging om de transactie met nonce 5 opnieuw uit te voeren, mislukt omdat het netwerk nu nonce 6 verwacht.
Dit is de reden waarom je dezelfde Ethereum-transactie niet twee keer op dezelfde blockchain kunt versturen: de nonce voorkomt dit. De valkuil die Gate.io in maart 2026 in een analyse identificeerde: een nonce alleen voorkomt herhaling binnen dezelfde blockchain, maar niet tussen verschillende blockchains, omdat verschillende blockchains afzonderlijke nonce-tellingen bijhouden.
Je account-nonce op het Ethereum-mainnet en je account-nonce op Ethereum Classic worden onafhankelijk van elkaar bijgehouden.
Een transactie met nonce = 5 op Ethereum kan ook nonce = 5 zijn op Ethereum Classic als je hetzelfde aantal transacties op beide blockchains hebt uitgevoerd. EIP-155 vult dit gat door de chainId onderdeel te maken van de handtekening zelf.
EIP-155 loste replay-aanvallen op transactieniveau op. Het biedt echter geen oplossing voor de verificatie van digitale handtekeningen in slimme contracten.
Wanneer een smart contract ecrecover gebruikt om een off-chain handtekening te valideren, verifieert het een bericht, niet een transactie. De chainId-bescherming van EIP-155 is van toepassing op de Ethereum-transactie die het bericht bevat, niet op de inhoud van het bericht zelf.
Als een ontwikkelaar een contract bouwt dat handtekeningen valideert zonder de chainId, het contractadres en de nonce in de ondertekende gegevens op te nemen, kunnen die handtekeningen door iedereen die ze onderschept, worden hergebruikt.
EIP-712 (Typed Structured Data Signing) behandelt dit probleem. Het definieert een standaardmanier om ondertekende berichten te structureren, inclusief een domeinscheidingsteken, een hash die de chainId, het adres van het verifiërende contract en de naam en versie van het contract bevat.
Een handtekening die is aangemaakt onder EIP-712 is gekoppeld aan een specifiek contract op een specifiek adres in een specifieke blockchain.
Het kan niet opnieuw worden uitgevoerd op een andere blockchain of een ander contract, zelfs niet als de bytecode identiek is.
Voor ontwikkelaars: voordat u een contract implementeert dat off-chain handtekeningen verifieert, moet u ervoor zorgen dat uw ondertekeningsschema alle drie de volgende elementen bevat: nonce (voorkomt hergebruik van hetzelfde bericht), chainId (voorkomt cross-chain replay) en contractadres (voorkomt cross-contract replay). De ECDSA-bibliotheek van OpenZeppelin, versie 4.7.3 en hoger, implementeert alle drie correct.
Afluistert onversleutelde netwerken met behulp van packet sniffers (bijvoorbeeld Wireshark).
2. vangen
Registreert geldige datapakketten (referenties, tokens of transactieverzoeken).
3. Analyse
Bereidt de vastgelegde pakketten voor op hergebruik zonder dat ze gedecodeerd hoeven te worden.
4. Herhaling
Verstuurt het geldige pakket terug naar het doelsysteem.
5. Uitvoering
Het systeem behandelt een dubbel verzoek als legitiem als er geen actualiteitscontroles zijn uitgevoerd.
Hoe voorkom je replay-aanvallen?
Beschermingsmethode
Hoe het werkt
Best gebruikt voor:
timestamps
Verzoeken met een tijdsinterval buiten het acceptabele bereik (bijv. 30s–1min) worden afgewezen.
Tijdgevoelige transacties en API-aanroepen
Unieke identificatoren / tokens
Voegt een eenmalig te gebruiken, willekeurig ID toe aan een verzoek en markeert het na gebruik om herhalingen te voorkomen.
Financiële transacties en sessie-ID's
Versleuteling (TLS / SSL / HTTPS)
Versleutelt gegevens tijdens de overdracht om te voorkomen dat tools voor het onderscheppen van datapakketten de onversleutelde tekst kunnen vastleggen.
Webapplicaties, beveiligde FTP en backendservices
Nonces (getallen die slechts één keer worden gebruikt)
Gebruikt een willekeurige of opeenvolgende waarde die direct ongeldig wordt zodra deze is verbruikt.
API-beveiliging en 2FA: tijdgebonden eenmalige wachtwoorden (TOTP)
Systemen en protocollen die kwetsbaar zijn voor replay-aanvallen
Doelsysteem / Protocol
Waarom het kwetsbaar is
Veelvoorkomende voorbeelden en fouten
Draadloze netwerken
Bij transmissie in de open lucht zijn gegevens gemakkelijk te onderscheppen en door te sturen.
Verouderde wifi (WEP/zwakke WPA) zonder pakketvolgorde; Bluetooth-apparaten zonder nonce-validatie of sessiekoppeling.
Cryptografische protocollen
Maakt gebruik van statische sleutels of mist contextbewuste actualiteitscontroles.
Kerberos of OAuth wanneer sessietokens of inloggegevens geen strikte tijdstempels en vervalregels hebben.
Internet of Things (IoT)
Geeft prioriteit aan een laag energieverbruik en gebruiksgemak boven robuuste beveiliging.
Slimme sloten en camera's die gebruikmaken van IoT-protocollen (MQTT, CoAP) zonder ingebouwde bescherming tegen herhalingen vanwege beperkte rekenkracht.
Betalingssystemen
Kwetsbaar als transacties geen dynamische, eenmalige authenticatiecodes bevatten.
Oudere contactloze kaarten en POS-terminals zonder EMV-cryptogrammen of tokens per transactie.
Replay-aanvallen hergebruiken vaak gegevens zonder de oorspronkelijke tijdstempel te wijzigen.
Door tijdstempels te controleren en te valideren, kunnen systemen detecteren wanneer berichten onverwacht vertraagd zijn of buiten een acceptabel tijdsvenster vallen.
Implementeer strikte, op tijd gebaseerde geldigheidscontroles voor tokens, transacties en API-aanroepen.
Markeer berichten die vertraagd lijken of buiten de normale sessieduur worden verwerkt.
Maak kruisverwijzingen naar systeemlogboeken om verzoeken met identieke tijdstempels die meer dan één keer voorkomen, te identificeren.
2. Detectie van dubbele berichten
Een belangrijk kenmerk van replay-aanvallen is de herhaling van identieke berichten of datapakketten.
Systemen moeten dergelijke patronen detecteren, met name op kritieke gebieden zoals authenticatie, financiële transacties en sessiebeheer.
Gebruik hashing of fingerprinting om dubbele pakketten of verzoeken te detecteren.
Vergelijk binnenkomende gegevens met recent verwerkte items om te controleren op herhaalde inhoud.
Registreer en onderzoek herhaalde sessietokens, API-aanroepen of gecodeerde payloads.
3. Volgnummer- en nonce-tracering
Beveiligde systemen maken vaak gebruik van volgnummers of nonces (nummers die slechts één keer worden gebruikt) om de uniciteit van gegevens te volgen en te valideren.
Bij herhaalde berichten wordt meestal dezelfde nonce of volgnummer hergebruikt, wat kan worden gemarkeerd.
Houd een kortetermijngeheugen (cache of database) bij van recent gebruikte nonces of volgnummers.
Verwijder of registreer verzoeken die hergebruikte waarden bevatten.
Waarschuwing over sessietokens of aanvraag-ID's die al zijn verwerkt.
4. Detectie van gedragsafwijkingen
Replay-aanvallen hoeven niet altijd technische kopieën te zijn; soms kan de gedragscontext de dreiging onthullen.
Een gebruiker die bijvoorbeeld binnen enkele seconden exact dezelfde transactie twee keer uitvoert, kan verdacht zijn.
Houd het gebruikersgedrag in de gaten en maak basisprofielen voor normale activiteiten.
Markeer afwijkende patronen, zoals herhaalde acties met een hoge frequentie, identieke verzoeken vanaf verschillende IP's of meerdere aanmeldingen met hetzelfde token.
Integreer systemen voor anomaliedetectie die kunnen leren en zich kunnen aanpassen aan typische verkeerspatronen.
5. Analyse van netwerkverkeer
Geavanceerde detectietools kunnen netwerkverkeer in realtime analyseren op zoek naar verdachte patronen, vooral in draadloze of IoT-omgevingen waar replay-aanvallen vaak voorkomen.
Gebruik Intrusion Detection Systems (IDS) of Wireless Intrusion Prevention Systems (WIPS) om verdachte pakkethertransmissies te detecteren.
Analyseer pakketheaders op hergebruikte identificatiegegevens, nonces of encryptieparameters.
Let op repetitieve gecodeerde payloads die niet variëren tussen sessies.
6. Analyse van sessietokens en authenticatielogboeken
Bij replay-aanvallen worden vaak hergebruikte authenticatietokens gebruikt. Systemen moeten de uitgifte en het gebruik van tokens controleren en analyseren om tokens te identificeren die hergebruikt of misbruikt lijken te zijn.
Houd de levensduur van sessietokens en de bijbehorende IP-/apparaatgegevens bij.
Registreert pogingen om verlopen of reeds gebruikte authenticatiegegevens opnieuw te gebruiken.
Onderzoek inlogpogingen die headers, metagegevens of sessiegegevens hergebruiken.
Wat is het verschil tussen een replay-aanval en een MITM-aanval?
Bij een replay-aanval worden geldige gegevens onderschept en opnieuw verzonden om een systeem te misleiden, terwijl bij een man-in-the-middle-aanval (MitM) de communicatie tussen twee partijen in realtime wordt onderschept en gewijzigd.
Wat zijn de meest voorkomende soorten pakketten die worden vastgelegd tijdens een replay-aanval?
De meest voorkomende typen pakketten die bij een replay-aanval worden onderschept, zijn authenticatieverzoeken, sessietokens, transactieberichten en besturingsopdrachten die worden gebruikt bij draadloze of netwerkcommunicatie.
Hoe voorkomt TLS een replay-aanval?
TLS voorkomt replay-aanvallen door gebruik te maken van unieke sessiesleutels, sequentienummers en bericht-authenticatiecodes (MAC's). Zo wordt gewaarborgd dat elk bericht actueel is en niet onopgemerkt opnieuw kan worden verzonden of gewijzigd.
Wat is een Kerberos-replayaanval?
Een Kerberos replay-aanval vindt plaats wanneer een aanvaller een geldig Kerberos-authenticatiebericht onderschept en opnieuw verzendt om het systeem ertoe te verleiden ongeautoriseerde toegang te verlenen zonder opnieuw te authenticeren.
Replay-aanvallen lijken misschien eenvoudig, maar de gevolgen kunnen ernstig zijn, variërend van ongeautoriseerde toegang tot financieel verlies en verstoring van de dienstverlening.
Het herkennen van kwetsbare systemen, het begrijpen van hoe deze aanvallen werken en het toepassen van gelaagde verdedigingsmechanismen zoals nonces, tijdstempels en encryptie zijn essentieel.
Omdat bedreigingen zich steeds vaker richten op zwakke punten in verificatieprocessen, worden vroege detectie en preventie van cruciaal belang.
Het versterken van systemen tegen replay-aanvallen gaat niet alleen over bescherming; het gaat erom vertrouwen, data-integriteit en consistente dienstverlening te waarborgen in digitale omgevingen waar de beveiliging niet in het gedrang mag komen.
Akindele T. Francis is een veelzijdige contentwriter met uitgebreide ervaring in diverse sectoren. Gespecialiseerd in blogposts, websitecontent, servicepagina's, overtuigende verkoopteksten, enzovoort, heeft Akindele samengewerkt met talloze bureaus om boeiend en effectief geschreven materiaal te leveren. Met een scherp oog voor detail en een passie voor het creëren van impactvolle verhalen, overtreft Akindele consequent de verwachtingen van klanten, boekt resultaten en versterkt de merkboodschap op diverse platforms.
Disclaimer : Dit artikel is uitsluitend bedoeld ter informatie en mag niet worden beschouwd als handels- of beleggingsadvies. Niets in dit artikel mag worden opgevat als financieel, juridisch of fiscaal advies. Handelen in of beleggen in cryptovaluta brengt een aanzienlijk risico op financieel verlies met zich mee. Voer altijd gedegen onderzoek uit voordat u handels- of beleggingsbeslissingen neemt.
Handel met bewijs van reserves
UEEx publiceert maandelijks audits en verificaties door derden voor elke beursgenoteerde markt.
Marktanalyses, handelsstrategieën, inzichten in futures en beveiligingswaarschuwingen worden wekelijks aangeleverd. Gelezen door meer dan 10,000 cryptohandelaren.
