Anti-phishingcode: een nuttig signaal dat je links niet controleert

Als je crypto.com, Binance of een vergelijkbare dienst gebruikt, ben je waarschijnlijk aangespoord om een "anti-phishingcode" in te stellen. Dat is een goede gewoonte, en dit artikel is geen pleidooi ertegen. Het gaat over wat de code wel en niet doet, want juist in het gat daartussen gaan mensen nog steeds de fout in.

Wat een anti-phishingcode is

Een anti-phishingcode is een woord of zin die je kiest en aan je account koppelt. De dienst neemt die vervolgens op in elke echte e-mail die hij je stuurt, zodat je iets specifieks hebt om naar te zoeken. Bij crypto.com stel je er één in voor de App en Exchange (die één gesynchroniseerde code delen) en een aparte, onafhankelijke voor het NFT-platform. Binance neemt je code op in zijn officiële e-mails en, zo zegt het, in zijn sms-berichten. Het patroon is overal hetzelfde: selfservice, één per account, getoond binnen de e-mail.

Kraken kiest een andere en sterkere route: het kan de e-mails die het je stuurt PGP-ondertekenen (zijn geautomatiseerde berichten kunnen een PGP-handtekening dragen). Dat is echte cryptografie in plaats van een herkenningszin, en het is het nuttige vergelijkingspunt voor alles wat volgt.

Waar hij goed in is

Tegen de klassieke merkimitatie-e-mail ("je account is geblokkeerd, bevestig nu") is de code een snelle controle in één oogopslag. Een echt bericht draagt de zin die jij en de dienst hebben afgesproken te verwachten; een vervalst bericht meestal niet. Een ontbrekende of verkeerde code is een onmiddellijke waarschuwing, nog voordat je een woord van de tekst hebt gelezen. Voor een maatregel die je één keer instelt en daarna nooit meer aanraakt, is dat echte waarde, en het is de moeite waard om in te stellen.

De blinde vlek: het zegt niets over links

Dit is wat de code je niet kan vertellen: waar een link naartoe wijst. Het zegt helemaal niets over de URL's in het bericht.

Het is de moeite waard om nauwkeurig te zijn over de grens. De code spreekt over de vraag "komt dit van het merk?" Kan een e-mail je dus ooit bereiken met de verwachte code en toch verwijzen naar een nagemaakte host? Niet doordat een aanvaller een echte e-mail onderweg herschrijft; zo werkt dit allemaal niet. Maar geauthenticeerde, vertrouwde verzendinfrastructuur kan wel degelijk kwaadaardige links afleveren, en doet dat ook. Het SendGrid-lek van januari 2026 (dat ik behandelde in het beleidsartikel dat hieronder is gelinkt) liet zien hoe aanvallers linkgebaseerde phishing verstuurden via een vertrouwd platform waarvan de post de authenticatie doorstond. Dat incident bewijst niet dat iemand een exchange-e-mail met de juiste code heeft vervalst. Maar het maakt de begrensde hypothese wel concreet: een gecompromitteerd mailsysteem van een dienst, of een aanvaller die simpelweg je code uit een eerdere echte e-mail heeft overgenomen, zou je in principe een bericht kunnen voorleggen dat de juiste code en de verkeerde link draagt.

Maar zet die hypothese even opzij, dan blijft het alledaagse punt overeind. De meeste phishing heeft je code helemaal niet nodig. Ze heeft nodig dat je er geen hebt ingesteld, of hem op het moment zelf niet controleert, en ze heeft een link nodig die op je exchange lijkt maar dat niet is.

Een signaal, geen geheim

Mensen noemen de anti-phishingcode vaak een "gedeeld geheim", en informeel wordt de functie ook zo verkocht: een geheim tussen jou en de dienst. Technisch houdt dat geen stand. Een waarde die leesbaar in elke echte e-mail wordt afgedrukt, is geen geheim meer zodra ook maar één van die e-mails is gezien. Ze is beter te omschrijven als een statisch herkenningstoken van het toonder-type: iedereen die één enkel echt bericht leest (een doorgestuurde ontvangstbevestiging, een screenshot, een gehackte mailbox, een gecompromitteerde marketingleverancier) heeft nu je code.

Dat bepaalt de grenzen ervan:

• Hij kan zelf worden gephisht. Een nep-pagina "bevestig je anti-phishingcode" oogst juist het token dat toekomstige phishingmail voor jou legitiem zou laten lijken.
• Hij is ervan afhankelijk dat je elke keer controleert. Dat is precies de gewoonte die urgentie is ontworpen om te doorbreken.
• Hij helpt alleen als je hem eerst instelt, en de meeste mensen doen dat nooit.
• Hij vermenigvuldigt zich over aanbieders. Elke aanbieder houdt zijn eigen code bij, en sommige houden er meer dan één: crypto.com gebruikt één code voor de App en Exchange, maar een aparte, onafhankelijke voor NFT. Om het signaal betekenisvol te houden wil je een andere zin voor elke onafhankelijke code, want hergebruik betekent dat één gelekte e-mail ze allemaal verzwakt. Zo hou je een groeiende verzameling statische zinnen te onthouden bij elke aanbieder, wat hergebruik in de hand kan werken of codes makkelijker doet vergeten, en een signaal dat je niet bijhoudt is stilletjes geen signaal meer.
• Hij is kanaalgebonden: e-mail, plus sms voor Binance, maar niets voor telefoongesprekken, chat-apps of pushmeldingen.
• Hij biedt geen cryptografische garantie. Anders dan DKIM (een cryptografische handtekening per bericht over een verzendend domein), DMARC (een beleid dat controleert of SPF en DKIM overeenstemmen met het zichtbare Van-domein) of BIMI (een door DMARC beveiligde merklogo-indicator) bewijst de code wiskundig niets. En geen van die drie staat in voor de inhoud van een bericht of voor waar de links naartoe leiden.

Twee vragen, twee lagen

Veilig e-mail lezen komt uiteindelijk neer op twee afzonderlijke vragen:

1. Ziet dit bericht er echt uit? De anti-phishingcode zegt hier weinig over. DKIM en DMARC voegen echt bewijs van domeinauthenticatie toe (een ondertekend verzendend domein, en een Van-domein dat op overeenstemming wordt gecontroleerd), maar alleen wanneer je mailsysteem het resultaat daadwerkelijk verifieert en toont, en zelfs dan bevestigen ze het domein, niet de inhoud of bedoeling van het bericht.
2. Wat is de onmiddellijke bestemming van deze link? Niets van het bovenstaande beantwoordt dit.

Bij die tweede vraag worden links aangeklikt en inloggegevens verloren, en het is de vraag die een anti-phishingcode nooit is gebouwd om te beantwoorden. De twee maatregelen zijn complementair, geen vervanging van elkaar: de code geeft je een hint over de afzender, en een hulpmiddel dat links onthult toont je de bestemming. Sterker nog, een hulpmiddel dat links onthult blijft juist werken wanneer de code je in de steek laat: bij een bericht dat de juiste code draagt maar ergens verkeerd naartoe wijst.

Zie de link voordat je klikt

Reveal URLs is het praktische antwoord op die tweede vraag. Het is gratis en opensource (AGPL). Voor elke link toont het de werkelijke onmiddellijke bestemming (de werkelijke URL) direct boven de link, en kleurt die rood zodra de host van die bestemming niet overeenkomt met een host die in de zichtbare linktekst wordt genoemd. Geen hover en geen lang indrukken: het verschil staat er standaard. Het toont de onmiddellijke URL en volgt geen redirects naar een uiteindelijke landingspagina, en het verifieert geen afzenders of authenticatie; dat is de taak van de andere laag.

Het is nu beschikbaar voor Chrome, Edge, Firefox, Thunderbird en Outlook, met de mobiele Outlook-versie en de Gmail-add-in nog in aantocht en Safari binnenkort.

Een anti-phishingcode is de moeite waard om in te stellen: hij is gratis, en een ontbrekende is een nuttige waarschuwing. Vraag hem alleen niet om een taak die hij niet aankan. Hij vertelt je dat een e-mail er echt uitziet; hij laat je nooit zien waar een link naartoe wijst. Om van elke link de onmiddellijke bestemming te zien, zie Reveal URLs: phishinglinks herkennen voordat je klikt, en voor het bredere argument dat e-mailprogramma's altijd de URL zouden moeten tonen, zie E-maillink-phishing: waarom je mailprogramma altijd de URL zou moeten tonen.