Passkeys en de phishing-relais: waarom origin binding wint van eenmalige codes
Phishing-kits die zich tussen gebruiker en echte inlogpagina nestelen zijn een van de betrouwbaarste manieren geworden om multi-factorauthenticatie te verslaan. Het slachtoffer tikt een eenmalige code in, de kit stuurt die binnen enkele seconden door naar de echte site, en de aanvaller houdt de sessie die terugkomt. Een passkey doorbreekt die relais zoals geen codemethode dat kan: er staat simpelweg niets op het scherm om te kopiëren.
Hoe AiTM-kits eenmalige codes oppeuzelen
Microsoft documenteerde de werking in detail: het volgde een campagne die vanaf september 2021 meer dan 10.000 organisaties trof. De aanvaller draait een reverse proxy die een pixelperfecte kopie van de echte inlogpagina serveert onder eigen domein en twee TLS-sessies vasthoudt: een met het slachtoffer, een met de echte site. Wachtwoorden en sessiecookies stromen door het midden, en de aanvaller logt in als de gebruiker. Microsoft benadrukte dat dit geen kwetsbaarheid in MFA is; de code is echt, de login is echt, en de kit houdt gewoon wat de gebruiker overhandigt (Microsoft). De techniek is niet verdwenen. In januari 2026 beschreven Microsoft-onderzoekers een meerstaps-AiTM-campagne tegen organisaties in de energiesector, die via misbruikte SharePoint-links binnenkwam en eindigde in financiële fraude (Microsoft). Een jaar Kaspersky-telemetrie, gepubliceerd in augustus 2026, telde ruim 390.000 phishingpagina's op legitieme cloudplatformen, veelal met open-sourceproxybibliotheken en browser-in-the-browser-vensters die de adresbalk vervalsen (Kaspersky). De moderne kit zendt code, pushgoedkeuring en de resulterende cookie in real time door. Alles behalve de URL is echt.Origin binding: het domein is deel van de credential
WebAuthn, de standaard achter passkeys, werkt anders. Bij registratie maken site en browser een publiek-privésleutelpaar dat is afgebakend tot een relying party ID, in de praktijk het domein van de site. De privésleutel verlaat het apparaat nooit, en de browser biedt een credential alleen aan als de origin van de pagina met dat ID overeenkomt. De documentatie van Mozilla brengt de consequentie rondborstig onder woorden: een aanvaller die een nep-inlogsite bouwt, kan niet als de gebruiker inloggen, want de handtekening verandert met de origin van de site (Mozilla). De FIDO Alliance beschrijft passkeys als uniek per website of applicatie — precies dat ontneemt credential stuffing de voedingsbodem (FIDO Alliance). Cisco Talos liet zien wat dit voor proxykits betekent: een slachtoffer dat op een nepdomein belandt dat zijn bank imiteert, kan de WebAuthn-ceremonie helemaal niet afronden, want de browser biedt een aan het echte domein gebonden credential niet aan op de nep. De authenticatie faalt voordat er ook maar een geheim wordt verzonden (Cisco Talos).Een proxykit kan alles doorgeven wat de gebruiker tikt. Een credential die de browser nooit aanbiedt, kan hij niet doorgeven.Ook waar de ceremonie wél loopt, kruist niets herbruikbaars de lijn. De server stuurt een heel grote willekeurige challenge, de authenticator ondertekent die met de privésleutel, en de handtekening bewijst het bezit zonder geheim prijs te geven, zoals de specificatie van Mozilla opmerkt. Een proxy kan die handtekening doorsturen, maar de echte site zou dan een antwoord zien dat een origin claimt die hij nooit serveerde, met een credential waarvan hij de relying party ID precies voor dit geval controleert. Er is geen code die tegen een timer van dertig seconden racet en geen cookie die aan de kant van de aanvaller wordt geslagen.