In het kort: Phishing en Adversary-in-the-Middle (AiTM)-aanvallen werken doordat een gestolen wachtwoord ook op de échte website geldig is. Bij MindYourPass wordt het wachtwoord berekend op basis van de bezochte domeinnaam, waardoor een phishingdomein automatisch een ander wachtwoord oplevert dan het legitieme domein. Zonder geldig wachtwoord komt er geen succesvolle login tot stand, en zonder login geen sessiecookie die een aanvaller kan overnemen. Dit biedt sterke bescherming tegen klassieke phishing én de meeste reverse-proxy-AiTM-aanvallen — als onderdeel van een gelaagde beveiligingsaanpak, want geen enkele losse maatregel dekt ieder denkbaar aanvalsscenario af. Hieronder lees je waarom.

‍

Phishing is nog altijd één van de meest succesvolle methoden om accounts over te nemen. Onderzoek van Verizon laat zien dat de menselijke factor, waaronder phishing en social engineering, in 2025 een rol speelde bij een groot deel van alle onderzochte datalekken. Waar aanvallers vroeger vooral probeerden gebruikers te verleiden hun wachtwoord prijs te geven, maken zij tegenwoordig steeds vaker gebruik van zogenoemde Adversary-in-the-Middle (AiTM)-aanvallen. Beveiligingsonderzoekers signaleren de afgelopen tijd zelfs een sterke toename van dit type reverse-proxy-aanvallen, mede doordat kant-en-klare AiTM-phishingkits steeds toegankelijker worden. Daarbij wordt niet alleen geprobeerd een wachtwoord te onderscheppen, maar de complete authenticatie tussen gebruiker en website.

Dat roept een logische vraag op:

Als een wachtwoord afhankelijk is van de website waarop je inlogt, beschermt dat dan ook tegen phishing en AiTM?

Het korte antwoord is: ja, in veel gevallen wel. Om te begrijpen waarom, is het belangrijk om eerst te kijken hoe traditionele wachtwoorden werken.
‍

Traditionele wachtwoorden

Bij een traditioneel account kies of genereer je één wachtwoord voor een website. Dat wachtwoord blijft hetzelfde totdat je het wijzigt.

Stel dat je een account hebt op:

https://bank.nl

en je wachtwoord is:

MijnGeheimeWachtwoord123

Bezoek je per ongeluk een phishingwebsite zoals:

https://bank-login-secure.com

en voer je daar hetzelfde wachtwoord in, dan beschikt de aanvaller direct over het wachtwoord waarmee ook op de echte website kan worden ingelogd.

Het probleem is dus niet alleen dat het wachtwoord wordt onderschept. Het probleem is óók dat hetzelfde wachtwoord ook geldig is op de echte website.

‍

Een domeingebonden wachtwoord werkt anders

MindYourPass werkt volgens een ander principe.

In plaats van websitewachtwoorden op te slaan, worden deze berekend op basis van meerdere factoren. Eén van die factoren is de geregistreerde domeinnaam van de website.

De MindYourPass-browserextensie of mobiele app leest automatisch de domeinnaam van de website waarop de gebruiker zich bevindt. Deze domeinnaam vormt één van de factoren in de wachtwoordberekening.

Daardoor ontstaat voor iedere website een uniek wachtwoord.

Het wachtwoord voor:

bank.nl

is dus altijd anders dan het wachtwoord voor:

bank-login-secure.com

zelfs wanneer alle andere factoren identiek blijven.

Wordt een andere domeinnaam bezocht dan waarvoor eerder een account is geregistreerd, dan beschouwt MindYourPass dit als een andere website en volgt automatisch een andere wachtwoordberekening.

‍

Waarom helpt dit tegen phishing?

Vrijwel iedere phishingwebsite gebruikt een andere domeinnaam dan de legitieme website.

Bijvoorbeeld:

Legitiem

https://bank.nl

Phishing

https://bank-login-secure.com

Omdat de domeinnaam onderdeel is van de wachtwoordberekening, ontstaat automatisch een ander wachtwoord.

Zelfs wanneer een gebruiker dit wachtwoord op de phishingwebsite invoert, beschikt de aanvaller niet over het wachtwoord dat hoort bij de echte website.

Het phishingdomein krijgt immers alleen het wachtwoord dat voor dát domein is berekend.

Het geldige wachtwoord voor bank.nl wordt eenvoudigweg niet gegenereerd.

Dat is een fundamenteel verschil met traditionele wachtwoorden.

‍

En hoe zit dat met AiTM?

Een Adversary-in-the-Middle (AiTM)-aanval gaat een stap verder dan een gewone phishingwebsite.

In plaats van alleen een nepwebsite te tonen, plaatst de aanvaller een reverse proxy tussen de gebruiker en de echte website.

Schematisch ziet dat er zo uit:

Gebruiker
    │
    ▼
login-bank-secure.com
    │
    ▼
bank.nl

Voor de gebruiker lijkt alles normaal.

De proxy stuurt de ingevoerde gegevens direct door naar de echte website en probeert de gebruiker ongemerkt succesvol te laten inloggen.

Bij traditionele wachtwoorden lukt dat vaak.

De echte website accepteert de inloggegevens en geeft vervolgens een sessiecookie af.

Omdat deze cookie via de proxy loopt, kan de aanvaller deze kopiëren en de sessie overnemen zonder het wachtwoord later opnieuw nodig te hebben.

Dit soort aanvallen is precies de reden waarom multi-factor-authenticatie (MFA) niet altijd de bescherming biedt die gebruikers ervan verwachten: AiTM-frameworks onderscheppen de sessie ná de MFA-stap, waardoor een tweede factor alleen op zichzelf de aanval niet stopt.

‍

Waarom werkt dat anders met een domeingebonden wachtwoord?

Het cruciale verschil is dat MindYourPass kijkt naar de domeinnaam waarop de gebruiker zich daadwerkelijk bevindt.

In bovenstaand voorbeeld is dat:

login-bank-secure.com

Niet:

bank.nl

Omdat de domeinnaam onderdeel is van de wachtwoordberekening, wordt een wachtwoord berekend voor login-bank-secure.com.

Wanneer de proxy dat wachtwoord vervolgens probeert te gebruiken op bank.nl, zal de echte website de authenticatie afwijzen.

Er ontstaat dus geen succesvolle login.

En zonder succesvolle login wordt ook geen sessiecookie uitgegeven.

Met andere woorden: de aanval strandt voordat een sessie kan worden opgebouwd.

‍

Verschil met een traditionele wachtwoordmanager

Ook moderne wachtwoordmanagers bieden een belangrijke bescherming tegen phishing.

Vrijwel alle bekende wachtwoordmanagers controleren of de domeinnaam overeenkomt met de website waarvoor een wachtwoord is opgeslagen. Bij een afwijkend domein vullen zij een wachtwoord doorgaans niet automatisch in.

Het verschil zit in de onderliggende aanpak.

Een traditionele wachtwoordmanager bewaart het wachtwoord in een versleutelde kluis. Het juiste wachtwoord bestaat dus al en kan – afhankelijk van de wachtwoordmanager en de handelingen van de gebruiker – alsnog worden opgezocht, gekopieerd of handmatig worden ingevuld.

MindYourPass werkt anders.

Het systeem bewaart het websitewachtwoord niet, maar berekent dit op basis van meerdere factoren, waaronder de geregistreerde domeinnaam.

Komt de bezochte domeinnaam niet overeen met de geregistreerde domeinnaam, dan wordt voor die website een andere wachtwoordberekening uitgevoerd.

Het wachtwoord dat hoort bij de legitieme website wordt op dat moment eenvoudigweg niet berekend.

Daardoor verschuift de beveiliging van een controle achteraf ("past dit opgeslagen wachtwoord bij deze website?") naar een eigenschap van de wachtwoordberekening zelf ("voor deze website bestaat een ander wachtwoord").

‍

En hoe verhoudt zich dit tot passkeys?

Wie zich verdiept in phishing-resistente authenticatie, komt al snel bij passkeys (gebaseerd op de FIDO2/WebAuthn-standaard) uit. Ook passkeys worden vaak als hét antwoord op AiTM gepresenteerd, en dat is niet zonder reden.

Bij een passkey draait het niet om een wachtwoord, maar om een cryptografisch sleutelpaar dat door de browser of het besturingssysteem wordt gekoppeld aan de origin (het exacte domein) waarvoor het is aangemaakt. Probeert een phishingwebsite een passkey te gebruiken die voor een ander domein is aangemaakt, dan weigert de browser dit al vóórdat er iets naar de aanvaller kan worden verstuurd. Dat maakt passkeys zeer sterk tegen phishing en AiTM.

Het onderliggende principe van MindYourPass is verwant: ook hier wordt de authenticatie gebonden aan het daadwerkelijke domein, waardoor een phishingdomein niets bruikbaars in handen krijgt. Het belangrijkste verschil zit in de vorm:

• Passkeys vervangen het wachtwoord volledig door een sleutelpaar, vastgelegd door het apparaat of de browser. Dit vraagt bredere ondersteuning vanuit de website of dienst zelf, en gebruikers zijn voor herstel en overdraagbaarheid vaak afhankelijk van het ecosysteem van hun besturingssysteem (bijvoorbeeld Apple, Google of Microsoft).
• MindYourPass blijft werken met een berekend wachtwoord, dat domeingebonden is. Dat maakt het te gebruiken op vrijwel elke website die een gewoon wachtwoordveld accepteert, zonder dat de website zelf iets hoeft aan te passen of passkeys hoeft te ondersteunen.

Met andere woorden: waar passkeys de authenticatiemethode zelf vervangen, past MindYourPass hetzelfde principe van domeinbinding toe binnen het bestaande, universeel ondersteunde wachtwoordmodel. Dat maakt het een praktisch alternatief voor situaties waarin passkeys (nog) niet overal beschikbaar of wenselijk zijn.

Het is daarbij goed om te weten dat dit geen kwestie van "of-of" hoeft te zijn. MindYourPass ondersteunt namelijk ook het beheren van passkeys, naast de domeingebonden wachtwoordberekening. Voor websites die passkeys aanbieden, kan een gebruiker dus voor die sterkste vorm van bescherming kiezen. Voor de vele websites die (nog) geen passkeys ondersteunen, blijft het domeingebonden wachtwoord een even phishing-resistente oplossing binnen het bestaande wachtwoordmodel. Zo is een gebruiker niet afhankelijk van het tempo waarin individuele websites passkeys uitrollen, maar toch consistent beschermd tegen phishing en AiTM.

‍

Waar de bescherming grenzen kent

Domeinbinding is krachtig, maar staat of valt met het correct herkennen van het domein. Een paar situaties zijn het vermelden waard:

• Look-alike domeinen (homograph-aanvallen). Een aanvaller kan een domein registreren dat er op het oog identiek uitziet maar technisch een ander domein is (bijvoorbeeld door gebruik van andere schrifttekens of subtiele tekenwisselingen). Voor MindYourPass is dit gewoon een ander domein, en dus wordt automatisch een ander wachtwoord berekend — precies zoals bedoeld. Het risico zit hier dus niet in de wachtwoordberekening, maar in de vraag of de gebruiker het verschil in de adresbalk zelf zou hebben opgemerkt.
• Gecompromitteerde subdomeinen van de legitieme website. Als een subdomein van de échte website zelf wordt overgenomen door een aanvaller, blijft dat technisch gezien hetzelfde geregistreerde domein. Domeinbinding is dan geen extra beveiliging tegen dat specifieke scenario; hiervoor blijft goede serverbeveiliging bij de websitebeheerder zelf nodig.

Dit zijn geen tekortkomingen van het principe an sich, maar een herinnering dat domeinbinding één, zeer effectieve laag is binnen een breder geheel van beveiligingsmaatregelen.

‍

Betekent dit dat AiTM volledig onmogelijk wordt?

Nee.

Het is belangrijk onderscheid te maken tussen verschillende aanvalstechnieken.

Een domeingebonden wachtwoord voorkomt dat een aanvaller via phishing of een reverse proxy het geldige wachtwoord voor de echte website verkrijgt.

Dat is een krachtige beveiligingslaag.

Maar er bestaan ook aanvallen die helemaal niet afhankelijk zijn van het wachtwoord.

Denk bijvoorbeeld aan:

• malware die al op het apparaat van de gebruiker aanwezig is;
• browser- of besturingssysteemcompromittering;
• kwetsbaarheden in een webapplicatie;
• diefstal van een reeds actieve sessie vanaf het apparaat van de gebruiker.

In die situaties ligt het aanvalspunt niet bij de authenticatie, maar elders.

Geen enkele wachtwoordtechniek - inclusief passkeys - kan dergelijke aanvallen volledig voorkomen.

‍

Een belangrijk onderscheid

Vaak wordt gezegd dat AiTM "sessies steelt". Dat is juist, maar alleen nadat een succesvolle authenticatie heeft plaatsgevonden.

Bij een domeingebonden wachtwoord kan die succesvolle authenticatie tijdens een phishing- of reverse-proxy-aanval juist uitblijven, omdat voor het phishingdomein een ander wachtwoord wordt berekend dan voor het echte domein.

Zonder succesvolle authenticatie ontstaat geen sessie.

En zonder sessie valt er ook niets over te nemen.

‍

Conclusie

Door de domeinnaam onderdeel te maken van de wachtwoordberekening ontstaat voor iedere website een uniek wachtwoord.

Daardoor kan een phishingwebsite nooit hetzelfde wachtwoord verkrijgen als de legitieme website.

Dat biedt niet alleen een sterke bescherming tegen klassieke phishing, maar voorkomt in veel gevallen ook dat een reverse-proxy-AiTM-aanval een geldige sessie kan opbouwen. Zonder succesvolle authenticatie wordt immers geen sessie uitgegeven die kan worden overgenomen.

Dat betekent niet dat alle vormen van accountovername onmogelijk worden. Aanvallen op het apparaat van de gebruiker, kwetsbaarheden in een webapplicatie, en randgevallen zoals gecompromitteerde subdomeinen blijven bestaan — net zoals bij elke andere authenticatiemethode, inclusief passkeys.

Wel wordt een belangrijk aanvalspad — het misbruiken van een wachtwoord via phishing of een reverse proxy — fundamenteel anders benaderd. Door het wachtwoord cryptografisch aan de domeinnaam te koppelen, is een wachtwoord dat voor de ene website is berekend simpelweg niet bruikbaar op een andere website.

‍

Bronnen: Verizon 2025 Data Breach Investigations Report; SpyCloud 2025 Identity Threat Report; KnowBe4 2026 Phishing Threat Trends Report.

‍