1. Wat is een vergunning?
Laten we beginnen met een verhaaltje over geld lenen:
Stel je voor dat ik 1 miljoen wil lenen van mijn vriend Jack Ma. Zonder te aarzelen pakt Jack de telefoon en belt de bank, bevestigt zijn identiteit en geeft opdracht om een opnamelimiet van 1 miljoen voor mij te autoriseren. De bank registreert deze autorisatie en ik hoef alleen maar naar de bank te gaan, mezelf te identificeren en het geautoriseerde bedrag op te nemen. Als de bank de machtiging niet kan vinden, wordt mijn verzoek geweigerd.
Laten we nu eens onderzoeken hoe dit proces verandert met een andere methode-Permit. In dit scenario, als ik Jack om 1 miljoen vraag, haalt hij terloops een cheque tevoorschijn, vult het bedrag in, ondertekent hem en overhandigt hem aan mij. Ik breng de cheque naar de bank en zelfs zonder een autorisatie record verzilvert de bank de cheque op basis van de handtekening van Jack.
Dit illustreert het verschil tussen Approve en Permit. Approve, een essentiële functie van ERC-20, wordt al veel gebruikt sinds de lancering van Ethereum. Maar waarom werd Permit later geïntroduceerd via ERC-2612 om hetzelfde effect te bereiken?
2. Waarom was een vergunning nodig?
Het ERC-2612 voorstel werd geïntroduceerd in maart 2019 en afgerond in oktober 2022. De ontwikkeling ervan viel samen met verschillende pieken in de gasprijzen van Ethereum. De razernij op de markt tijdens bull runs leidde ertoe dat gebruikers meer uitgaven aan gasvergoedingen voor snellere transacties, waarbij zelfs een voordeel van één blok een aanzienlijke winst kon betekenen.
Dit fenomeen creëerde echter een last voor gebruikers, omdat het twee-transactie proces dat nodig was voor Approve duur werd, vooral voor degenen met kleinere fondsen. De introductie van Permit maakte offline ondertekenen mogelijk, waardoor de noodzaak voor onmiddellijke on-chain autorisatie wegviel. Deze verandering betekende dat de autorisatie kon worden gegeven naast de tokenoverdracht, vergelijkbaar met het verzilveren van een cheque zonder dat voorafgaande goedkeuring van de bank nodig was.
Hoewel dit voordelig leek – Jack een telefoontje besparen en de transactiekosten voor gebruikers verlagen – opende het onbedoeld de doos van Pandora.
3. De snelle toename van risico’s
Vóór Permit vertrouwden hackers vaak op phishingmethodes waarbij gebruikers hun handtekening moesten zetten onder Approve-transacties. Zelfs als gebruikers per ongeluk klikten, konden ze dankzij de tijdvertraging voor on-chain transacties de actie ongedaan maken met een nieuwe transactie.
De vergunning heeft het spel echter veranderd. Het elimineert benzinekosten en vereist alleen een handtekening, wat de waakzaamheid van de gebruiker verlaagt. Omdat de handtekening offline is, kunnen hackers de controle overnemen en misbruik maken van de situatie wanneer ze maar willen, waardoor hun winsten gemaximaliseerd worden.
De impact van deze verschuiving is duidelijk zichtbaar in het stijgende aantal phishing-slachtoffers en de gestolen bedragen. Volgens @ScamSniffer:
- In 2023 liepen de verliezen door phishing op tot 295 miljoen dollar.
- Halverwege 2024 was dat bedrag al opgelopen tot meer dan 314 miljoen dollar.
- In Q3 2024 was een belangrijk incident waarbij een portemonnee het slachtoffer werd van een Permit phishing-aanval, wat resulteerde in een verlies van 12.000 $spWETH, ter waarde van ongeveer $30 miljoen.
Dergelijke uitkomsten waren waarschijnlijk niet voorzien door de ontwikkelaars die Permit voorstelden, in eerste instantie gericht op het verlagen van de gaskosten en het verbeteren van de gebruikerservaring. Wat bedoeld was als een tweesnijdend zwaard, bleek een scherp mes te zijn dat door de beschermende barrières rond de bezittingen van gebruikers sneed.
Er zijn vergelijkbare offline ondertekeningsmethoden opgedoken, zoals Permit2 van Uniswap, wat de afhankelijkheid van offline ondertekening vergroot en phishing-risico’s vergroot.
4. Hoe bescherm je jezelf
Met het oog op deze dreiging kunnen gebruikers verschillende voorzorgsmaatregelen nemen om verliezen te beperken:
1. Bewustzijn vergroten
- Blijf voorzichtig met Airdrop-verleidingen: Airdrops kunnen aanlokkelijk zijn, maar veel ervan zijn phishingpogingen. Controleer altijd de legitimiteit van een airdrop via meerdere bronnen voordat u deelneemt.
- Blind tekenen vermijden: Als je per ongeluk op een phishingsite terechtkomt en er verschijnt een transactievenster, bekijk dan de transactiedetails nauwkeurig. Termen als Permit, Permit2, Approve of IncreaseAllowance duiden op mogelijke autorisatieproblemen, waardoor voorzichtigheid geboden is. Hardware wallets zoals Keystone kunnen helpen door transactie details te ontleden en weer te geven, waardoor impulsieve acties worden voorkomen.
2. Gereedschappen gebruiken
- ScamSniffer: Deze browserextensie waarschuwt gebruikers voordat ze verdachte URL’s invoeren, zodat ze interacties direct kunnen stopzetten.
- Intrekken: Revoke.cash toont tokenautorisatierecords in je portemonnee en adviseert gebruikers om verdachte of onbeperkte autorisaties in te trekken. Het regelmatig opschonen van autorisaties minimaliseert risico’s.
3. Vermogensisolatie en multi-handtekeningportefeuilles
Het adagium “leg niet al je eieren in één mandje” geldt ook voor crypto-activa. Bewaar belangrijke activa in koude portemonnees zoals Keystone en gebruik kleine warme portemonnees voor dagelijkse transacties. Op deze manier, zelfs als één wallet gecompromitteerd is, lopen niet alle activa gevaar.
Portemonnees met meerdere handtekeningen kunnen voor extra beveiliging zorgen. Tegoeden zijn alleen toegankelijk met een vooraf bepaald aantal goedkeuringen van de portemonnee, zodat een enkele gecompromitteerde portemonnee niet leidt tot een volledig verlies.
5. Conclusie
Hoewel we de waarde van Permit niet kunnen ontkennen, suggereert het toenemende aantal diefstallen dat de risico’s groter zijn dan de voordelen. Net als de ooit veelgebruikte ethsign-methode, die uiteindelijk werd afgeschaft vanwege beveiligingsproblemen, staat Permit nu voor een kritiek moment. Ontwikkelaars moeten zorgvuldig overwegen of ze deze methode willen verbeteren of opgeven.
-
-
-
-
-
-
-
-
