Risico's bij ondertekenen met je wallet: approval- vs. transactie-handtekening

Elke keer dat je wallet een handtekeningverzoek toont, doen de meeste mensen hetzelfde: een blik erop, snappen het niet helemaal, willen deze stap gewoon afmaken, klikken op akkoord. En daar zit precies het probleem — het ondertekenen zelf verschilt hemelsbreed in gewicht. Sommige handtekeningen bewijzen alleen "ik ben de eigenaar van deze wallet", en die zijn onschuldig. Andere staan gelijk aan het weggeven van het recht om over je bezit te beschikken; die ondertekenen is niet anders dan je kluis openzetten. Ze zien er in de pop-up soms erg op elkaar lijkend uit — kosten allebei geen gas, laten je allebei op akkoord klikken — maar de gevolgen liggen mijlenver uiteen.

In dit artikel pluis ik de gebruikelijke soorten handtekeningen één voor één uit: welke alleen je identiteit bewijzen, welke echt aan je geld komen, waarom een offline-handtekening als permit valser is dan een gewone approval, waarom je een eth_sign blind signing meteen moet wegklikken, en het praktischst van alles — hoe je vóór het klikken die ene regel leest die je vraagt wat er eigenlijk gebeurt. De techniek klopt, maar ik vertaal alles naar gewone taal. Je hoeft na afloop geen developer te zijn geworden, maar je zou bij een pop-up moeten kunnen pauzeren en onderscheiden of dit "bewijzen dat ik ik ben" is of "een recht weggeven". Voor de volledige aanpak van approvals zelf lees je dit samen met Wallet-approvals: controleren en intrekken.

De gebruikelijke soorten handtekeningen in je wallet

Bouw eerst een ruwe kaart. De verzoeken die je in je wallet tegenkomt vallen grofweg in twee grote categorieën, en dat onderscheid begrijpen is de basis voor al het volgende.

• Transactie (transaction). Verandert de on-chain-staat echt, kost gas, moet in een blok worden verwerkt. Gewone overdrachten, approve-approvals en contract-interacties (swappen, minten enzovoort) vallen hieronder. Kenmerk: er zijn transactiekosten, en de wallet toont meestal wat deze transactie doet en hoeveel er beweegt.
• Handtekening (signature / berichthandtekening). Je zet met je private key een cryptografische handtekening op een stuk data, en dat gaat niet per se on-chain en kost meestal geen gas. Het kan puur je identiteit bewijzen (bijvoorbeeld inloggen bij een DApp), maar het kan ook een "machtiging" zijn die de tegenpartij on-chain gebruikt (zoals permit), of ruwe data waarvan je de betekenis niet ziet (eth_sign blind signing).

Het gevaarlijke misverstand van veel mensen zit in die tweede categorie — "het kost toch geen gas en het is geen overdracht, wat kan er nou van een handtekening misgaan". Precies andersom: de meest sluipende on-chain-phishing leunt erop dat je een ogenschijnlijk onschuldig bericht ondertekent. Over de cryptografische basis achter handtekeningen en de relatie tussen transacties en handtekeningen op Ethereum geeft de transactiedocumentatie van de Ethereum Foundation een systematisch beeld, als je de basis wilt leggen.

Gewone transactie: de richting is geld dat wegstroomt

Het makkelijkst te begrijpen is de gewone overdracht. Je wilt wat munten van je eigen adres naar een ander adres sturen, je wallet toont een transactie waarin je het ontvangstadres, het bedrag en de globale gas bevestigt. Onderteken je, dan gaat de transactie on-chain en zijn de munten weg.

De risicopunten zijn hier vrij direct, en er zijn er vooral twee: ten eerste dat het ontvangstadres fout is of vervangen — bij het plakken door clipboard-hijacking-software vervangen door het adres van een aanvaller, of je hebt een paar tekens verkeerd overgenomen; ten tweede dat je het verkeerde bedrag stuurt. Anders dan bij een approval geef je geen "langdurig recht" weg. Het verlies is meestal eenmalig en beperkt tot dat wat je deze keer overmaakt. Maar omdat je rechtstreeks geld stuurt, is een fout onomkeerbaar, dus het adres controleren vóór de overdracht is extra belangrijk. Onze adrescontrole-tool helpt je bevestigen dat het adresformaat klopt en niet verkeerd is overgenomen; de gewoonte om "vóór een overdracht de eerste en laatste tekens van het ontvangstadres tegen elkaar te leggen" is ook goud waard.

Onthoud één kenmerk van deze categorie: de richting is "geld dat bij jou wegstroomt", en het bedrag en de partij staan glashelder in de pop-up. Dat maakt dit juist relatief transparant — je ziet wat er gaat gebeuren. Echt vals zijn de handtekeningen hierna, die "niet lijken alsof er geld beweegt".

Contract-interactie: je roept een functie aan

Als je in een DApp iets doet — op een DEX munten swappen, geld aan een liquiditeitspool toevoegen, een NFT minten — start je in werkelijkheid een transactie die "een bepaalde functie van een bepaald contract aanroept". Je wallet toont die ter bevestiging, en ook dit valt onder de transacties die gas kosten.

Het risico bij deze handtekeningen is dat je niet per se ziet wat je aanroept. Een nette wallet probeert de transactie zo veel mogelijk te "decoderen" naar gewone taal en vertelt je met welk contract je interacteert, wat het ongeveer doet en welke tokens het mogelijk beweegt; maar als het contract niet geverifieerd is of de interactie complex is, toont de wallet soms alleen een reeks onbegrijpelijke data. Wat een smart contract is en waarom je vóór een interactie het liefst bevestigt dat een contract te vertrouwen is, staat basaal uitgelegd in de smart-contract-documentatie van de Ethereum Foundation.

Binnen de contract-interacties verdient er één aparte behandeling: de approve-approval, want dat is de vorm die phishing het vaakst misbruikt. De volgende sectie gaat daar apart over.

approve-handtekening: het recht om tokens te bewegen weggeven

approve is een bijzondere contract-interactie: je verplaatst geen munten, maar vertelt een tokencontract "ik sta toe dat een bepaald adres (spender) maximaal N stuks van dit token onder mijn naam wegneemt". Die N heet de allowance. Na de approval hoeft, zolang de allowance niet op is, dat goedgekeurde contract niet opnieuw te laten ondertekenen om dit soort token telkens weer weg te nemen. Dat is het mechanisme waarop DeFi automatisch draait en op zich geen probleem.

Het gevaar heeft twee lagen. Ten eerste vragen veel DApps standaard een N aan die bijna oneindig groot is (onbeperkte approval), uit gemakzucht, wat betekent dat dit contract — zodra het kwaadaardig is of later gekraakt wordt — je token volledig kan wegnemen. Ten tweede verpakt een phishingpagina "airdrop claimen" als een approve naar het eigen contract — jij denkt dat je tokens claimt, terwijl je het adres van de oplichter een langdurig recht geeft om een bepaald token bij je leeg te halen.

Over het volledige mechanisme van approve, de gevaren van onbeperkt en hoe je al verstrekte approvals bekijkt en intrekt, gaat Wallet-approvals: controleren en intrekken uitgebreid. Hier benadruk ik één beoordeling: als de handeling "claimen" van jou vraagt om te approven, om het recht om tokens te bewegen weg te geven, dan is de richting omgedraaid. Normaal claimen is: munten stromen naar jou, jij betaalt zelf gas om te claimen. Approval-phishing is: het recht stroomt naar hén. Verkeerde richting is rood licht. Voor het intrekken van al verstrekte approvals gebruik je de officiële tool revoke.cash.

Waarom de permit (EIP-2612) offline-handtekening gevaarlijk is

Nu de belangrijkste soort van het hele artikel — permit. Ze is gevaarlijk juist omdat ze "er te onschuldig uitziet".

Eerst de bedoeling. Ethereum heeft een verbeteringsvoorstel genaamd EIP-2612 dat ERC-20 een permit-functie geeft, waardoor een approval via een offline-handtekening kan worden geregeld in plaats van via een aparte approve-transactie die gas kost. Oftewel: je ondertekent een gestructureerd bericht (niet on-chain, kost geen gas), en de tegenpartij kan met die handtekening on-chain iets doen wat gelijkstaat aan een approve. Het doel is een transactie besparen, gas besparen en het gebruik soepeler maken. Het formaat van deze gestructureerde handtekening is gebaseerd op een ander voorstel, EIP-712, dat de inhoud van de handtekening in relatief leesbare velden laat tonen. De originele voorstellen staan in EIP-2612 en EIP-712.

Het gevaar zit hierin: voor een gewone gebruiker zien een permit-bericht ondertekenen en een gewoon login-bericht ondertekenen er in de pop-up ongeveer hetzelfde uit — allebei kosten geen gas, allebei "even op akkoord klikken". Oplichters schrijven de phishingpagina als "onderteken om je airdrop-aanspraak te verifiëren" of "onderteken om in te loggen". Jij denkt dat je alleen bewijst dat je de eigenaar van de wallet bent, maar in werkelijkheid onderteken je een permit — toestemming voor de tegenpartij om een bepaald token van je te bewegen. Na het ondertekenen verandert de pagina misschien helemaal niets, en tegen de tijd dat je het doorhebt, heeft de tegenpartij met jouw handtekening on-chain de approval afgerond en je bezit weggehaald.

permit is valser dan gewone approve-phishing, om drie redenen: het kost geen gas, waardoor de psychologische drempel van "betalen en nog een keer bevestigen" wegvalt; het gaat (op het moment dat je ondertekent) niet on-chain, dus je ziet er in je eigen transactiegeschiedenis even geen spoor van; en als de wallet de pop-up niet goed parseert, is het makkelijk te verwarren met een gewone handtekening. Daarom lopen veel on-chain-diefstallen bij particulieren de laatste jaren via een handtekening in plaats van via het direct aftroggelen van de private key.

eth_sign blind signing: de pop-up om het meest voor op te passen

Er is nog een primitiever en gevaarlijker verzoek: eth_sign. Daarmee onderteken je een stuk ruwe data waarvan de betekenis niet te zien is (meestal een reeks hexadecimale hash), en de wallet kan het niet naar gewone taal vertalen om je te vertellen wat je precies ondertekent. Dit heet in de volksmond "blind signing".

Het probleem: die onbegrijpelijke data kan in theorie van alles zijn — een approval, een overdracht, een permit. Onderteken je, dan is het alsof je een stempel zet op een document dat leeg is maar wel rechtsgeldig; wat de tegenpartij invult, geldt. Legitieme DApps vragen zelden eth_sign, juist omdat het te gevaarlijk is, en mainstream wallets (zoals MetaMask) tonen bij zo'n verzoek standaard een opvallende waarschuwing en hebben het soms standaard uitgeschakeld. Het risico van de diverse handtekeningmethoden en hoe de wallet ermee omgaat: houd de officiële documentatie van jouw wallet aan, bijvoorbeeld het MetaMask Support-centrum, dat er speciaal uitleg over heeft.

De voorgaande soorten naast elkaar, zodat je bij een pop-up snel kunt inschatten:

Hoe je een handtekeningverzoek leest

Breng de bovenstaande kennis terug naar de paar seconden vóór de pop-up. Dit is de gedachtegang die ik zelf elke keer vóór het ondertekenen doorloop. Ze garandeert niet dat je alles doorziet, maar houdt de overgrote meerderheid tegen.

• Vraag eerst: "wat dacht ik dat ik hier deed". Stond er op de knop die je klikte "inloggen / verbinden / claimen / swappen"? Houd je verwachting vast en leg die zo dadelijk naast de inhoud van de pop-up.
• Kijk of het een transactie of een handtekening is. Met gas en de tekst "transactie bevestigen" is een transactie; zonder gas en alleen "ondertekenen" is een berichthandtekening. Bij die laatste moet je de inhoud extra goed lezen, verslap niet omdat het niets kost.
• Lees de sleutelvelden. Komen Permit, spender, value, approve of setApprovalForAll voorbij, dan geef je een recht weg, geen simpel identiteitsbewijs. Zie je eth_sign / "ruwe data" / "inhoud kan niet worden getoond", weiger dan.
• Leg de richting tegen elkaar. Jij dacht "claimen / inloggen", maar de pop-up zegt "approve / permit" — verwachting en inhoud kloppen niet, en dat is een gevaarsignaal.
• Controleer de goedgekeurde partij. Is het inderdaad een approval, kijk dan of de spender wel een contract is dat je vertrouwt, en zoek het adres desnoods op in een blockchain-explorer (zoals Etherscan) om de herkomst na te gaan.
• Klopt het niet, weiger. Weigeren kost vrijwel niets — hooguit doe je deze handeling niet. Op akkoord klikken is het onomkeerbare. Weiger liever een paar keer te veel dan één keer te gokken.

De kern is eigenlijk één zin: onderteken pas als de wallet je in gewone taal duidelijk kan vertellen "je geeft recht X aan Y" én dat precies is wat je wilde; is de inhoud vaag of klopt ze niet met wat je dacht te doen, weiger dan. Een nette wallet probeert de inhoud voor je te parseren, dus een goed onderhouden, sterk parserende mainstream-wallet is op zich ook een beschermlaag — houd voor de veiligheidsinstellingen de officiële documentatie aan (bijvoorbeeld het MetaMask Support-centrum).

Veilige gewoontes die je opbouwt

Om de losse beoordelingen in spiergeheugen te veranderen, hieronder een paar dingen die ik zelf voortdurend gebruik.

Pauzeer drie seconden vóór het ondertekenen en zeg "wat wil het van me bewegen"

Vrijwel elke oplichting leunt op tijdsdruk zodat je niet toekomt aan nadenken. Draai dat om: dwing jezelf om vóór elke akkoord-klik drie seconden te pauzeren en de sleutelvelden in de pop-up hardop te benoemen — is dit inloggen of approven? Klopt de richting? Dat kleine gebaar houdt de meeste "zonder nadenken geklikt"-ongelukken tegen.

Wallets scheiden: laat de experimenteer-wallet de klappen opvangen

Zet langetermijnbezit in een "kluis-wallet" die vrijwel geen DApp verbindt (het liefst met een hardware-wallet), en open een aparte "experimenteer-wallet" met slechts een klein bedrag, speciaal voor het verbinden van nieuwe sites, airdrops claimen en van alles ondertekenen. Ondertekent de experimenteer-wallet ooit iets fout, dan blijft het verlies beperkt tot dat kleine bedrag. Dit is de meest kosteneffectieve verdedigingslinie. Voor het bijbehorende bewaren van private key en seed phrase, zie Seed-phrase-veiligheid.

Ga via een bladwijzer naar de officiële site, zoek niet ter plekke

De bron van veel gevaarlijke handtekeningen is een namaaksite. Bewaar de officiële sites van projecten die je vaak gebruikt en je vaste tools als bladwijzer en ga er elke keer via die bladwijzer heen, om namaaksites al bij de ingang te vermijden. Meer trucs om nep-airdrops en nep-claimpagina's te herkennen, staan in Nep-airdrops en approval-phishing. En als je eerst de basis van een Web3-wallet op orde wilt hebben, lees dan Web3-wallet uitgelegd.

Trek periodiek in en haal weggegeven rechten terug

Handtekeningen (vooral de approvals die na een approve of permit van kracht worden) stapelen zich op. Maak er een gewoonte van om periodiek met revoke.cash ongebruikte approvals te controleren en in te trekken, en zo allang vergeten oude rechten terug te halen. Wil je tegelijk het risico nalopen, gebruik dan onze Approval-risico-checklist als naslag.

We hebben onszelf later een keiharde regel opgelegd: alles wat bij "airdrop claimen / aanspraak verifiëren" opduikt en om een handtekening vraagt, behandelen we standaard als een permit, als een approval, in het slechtste geval — eerst de velden goed bekijken, dan pas beslissen. Die regel heeft ons heel wat handtekeningen laten weigeren, en achteraf bleek: met die geweigerde was meestal echt iets mis.

Tot slot. Een wallet-handtekening is niet één handeling, maar een categorie handelingen, van "bewijzen dat ik ik ben" tot "de kluissleutel weggeven". Houd ze uit elkaar — bij een overdracht adres en bedrag controleren, bij een approval de partij en de allowance controleren, permit behandelen als een onzichtbare approval, en eth_sign blind signing zonder uitzondering weigeren — en combineer dat met de gewoontes van drie seconden pauzeren, wallets scheiden, via een bladwijzer gaan en periodiek intrekken. Dan weet je bij dat ogenschijnlijk achteloze "op akkoord klikken" echt wat je ondertekent.