TL;DR: Om impersonatie, waaronder identiteitsfraude, beter te kunnen bestrijden, stel ik voor dat we met een andere defintitie van authenticatie gaan hanteren dan tot nu toe gebruikelijk: het doel van authenticatie moet zijn het zoveel mogelijk voorkómen van impersonatie. Tevens moeten alle betrokkenen meer rekening gaan houden met slachtoffers t.g.v. het (onvermijdelijk) in een deel van de gevallen falen van het authenticatiesysteem.

In https://security.nl/posting/792302 kun je lezen dat een 71-jarige voor 70.000 euro werd bestolen, er meerdere bankrekeningen op zijn naam werden geopend en artikelen op zijn naam werden besteld en hij daardoor ruim 2 jaar in de ellende heeft gezeten. Uiteindelijk heeft hij het geluk dat zijn fincanciële schade beperkt blijft - mede doordat verdachten zijn opgepakt. Maar niet iedereen heeft zoveel geluk bij ongeluk.

Kort gezegd: de sterkte van authenticatie is evenredig met hoe moeilijk impersonatie is.

Nb. dit is een zeer lang artikel. Stop met lezen als je daar niet van houdt!

Inleiding
De afgelopen jaren ben ik flink in authenticatie, identiteitsfraude en impersonatie gedoken en ik leer elke dag bij. Dit artikel plaats ik in de hoop op minder slachtoffers en betere hulp aan hen die toch slachtoffer worden, maar ook om kennis te nemen van andere inzichten - mochten die bestaan en lezers reageren; ik hoop op een boeiende en to-the-point discussie!

In dit artikel probeer ik uit te leggen waarom ik denk dat het doel van het authenticatieproces onvoldoende wordt begrepen. De toename van digitalisering en cybercrime alsmede snelle ontwikkelingen in de AI (Artificiële Intelligentie) leiden tot een sterk toenemend aantal gevallen van impersonatie (variërend van "geintjes" tot ernstige vormen van identiteitsfraude met soms enorme impact).

Authenticatie is lastig: zie https://www.gov.uk/government/publications/identity-proofing-and-verification-of-an-individual/how-to-prove-and-verify-someones-identity.

Belangrijk: Je krijgt authenticatie nooit 100% betrouwbaar, want sowieso gaat het hierbij altijd om een keten met schakels van verschillende sterkte. Je moet dus altijd voorbereid zijn op, en rekening houden met, slachtoffers - want die zullen er atijd zijn. Ook is het op z'n minst niet fair als je geen rekening houdt met mensen die niet kunnen of willen deelnemen aan jouw authenticatiesysteem, vooral indien jouw systeem ertoe leidt dat bestaande systemen worden afgebouwd en/of verzwakt.

Begrippen
Nb. De termen "relatief" en "absoluut" in relatie tot authenticatie heb ik zelf bedacht; ik heb (wellicht niet goed genoeg) naar iets dergelijks gezocht op internet, maar niets geschikts gevonden.

Entiteit: een uniek identificeerbaar "object" dat niet tastbaar en niet uniek hoeft te zijn. Denk aan een mens, ChatGPT of een ander "draaiend" proces op een computer (bijvoorbeeld onder Windows kun je meerdere lege instanties van het programma "Kladblok" = notepad.exe starten).

Impersonatie: een proces dat leidt tot het onterecht verwisselen van twee entiteiten door een verifieerder met significante negatieve gevolgen voor één of meer slachtoffers. Een Engels woord voor een impersonator is impostor (waar bij mijn weten geen passend werkwoord voor bestaat).

Non-repudiation: wishful thinking (soms levensgevaarlijk) voor dat "iemand niet kan ontkennen dat hij het was". Van sommigen worden bijvoorbeeld social media accounts gehacked waarna zij geen mogelijkheid meer krijgen om aan te tonen dat zij de oorspronkelijke "bezitter" waren (voorbeeld: https://radar.avrotros.nl/nieuws/item/kunstenaar-lucienne-55-voelt-enorme-leegte-na-instagram-hack-ik-had-echt-iets-opgebouwd/).

Absolute identificatie: een verifieerder krijgt (evt. tijdelijk) toegang tot "wettelijke" uniek identificerende gegevens van een entiteit. Met "wettelijke" bedoel ik gegevens zoals die je op identiteitsbewijzen kunt vinden (inclusief BSN en bijvoorbeeld paspoortnummer).

Partiële identificatie: een verifieerder krijgt (evt. tijdelijk) toegang tot één "wettelijk" identificerend gegeven (of een beperkte set daarvan) van een entiteit. Het doel hierbij is vaak dat de anonimiteit zoveel mogelijk gewaarborgd wordt, terwijl bijvoorbeeld getracht word om te jonge mensen geen toegang te geven tot iets dat uitsluitend bedoeld is voor volwassenen.

TOFU: Trust On First Use. De meeste accounts op internet (zoals op security.nl, tweakers.net en "gratis" e-mailaccounts) kun je aanmaken door aan te tonen dat je toegang hebt tot een bestaand e-mailaccount (dat niets over jouw identiteit hoeft te zeggen, zoals draakje864@hotmail.jeweetwel of zelfs een wegwerpaccount kan zijn). En als er om identificerende gegevens wordt gevgaagd, kun je daar meestal over liegen.

Relatieve identificatie: TOFU; tijdens het aanmaken van het account kies je meestal een wachtwoord en/of andere "authenticatiefactoren". Elke volgende keer dat je inlogt, moet je bewijzen dezelfde entiteit te zijn als tijdens het aanmaken van het acccount. Dit zou je ook het aantonen van een pseudonieme identiteit kunnen noemen.

Pseudonieme identiteit: bijvoorbeeld "Erik van Straten" op security.nl, e-mailadressen, domeinnamen (o.a. van websites) en telefoonnummers. Je weet uitsluitend op basis van deze gegevens niet precies om wie het gaat, ze kunnen vaak eenvoudig van eigenaar wisselen of gehacked worden, of worden vervalst.

AitM: Attacker in the Middle (of Aanvaller in het Midden). Hierbij maak jij verbinding met een kwaadwillende in plaats van met de bedoelde partij, waarna die kwaadwillende zich voordoet als jou richting de bedoelde partij. Dit kan door jou te misleiden (phishing) of door technische ingrepen buiten jouw invloedsfeer (zoals een nep telefonie-zend-ontvanger die jouw uitgaande gesprekken naar een ander nummer stuurt, of een BGP-hijack op internet), of doordat jouw apparatuur gecompromitteerd is (recent voorbeeld: https://www.bleepingcomputer.com/news/security/hackers-use-rilide-browser-extension-to-bypass-2fa-steal-crypto/). Bij zo'n aanval is zwakke MFA zoals TOTP kansloos, zoals ik probeer uit te leggen in https://security.nl/posting/773644.

Uitgangspunt: authenticatie *NU*
Uit https://nl.wikipedia.org/wiki/Authenticatie:
Omdat de verifieerder ook een computer kan zijn, zoals een toegangscontrolesysteem met een paslezer of zelfs gezichtsherkenning, maak ik daarvan (dit is nog steeds een m.i. onjuiste defintitie):

Probleem: misleiding, impersonatie
Een voorbeeld. Als een website als domeinnaam zoals:
heeft en daarmee 2FA inloggegevens steelt (zie https://security.nl/posting/768888), is dat in beginsel géén identiteitsfraude.

Impersonatie van websites vindt ook plaats met nog veel sterker afwijkende domeinnamen, en bovendien hoeft zo'n inlogpagina niet als twee druppels op het origineel te lijken. Zodra één of meer entiteiten hier "intrappen", vind ik zoiets in elk geval impersonatie. Ook is zo'n nepwebsite duidelijk niet authentiek.

In https://www.merriam-webster.com/dictionary/authentic worden voor het begrip authentic als synoniemen genuine en bona fide genoemd; met geen van allen heeft zo'n nepwebsite iets te maken. Zolang we van geslaagde authenticatie blijven spreken als een impersonator met succes ergens inlogt als zijnde een slachtoffer, gaat er niks ten goede veranderen.

Voorbeeld: wie is de verifieerder?
Merk op dat de slachtoffers in bovenstaand voorbeeld, na ontvangst van een phishingbericht, met MFA, inlogden op hxxps://circle-ci.com/, óók verifieerders waren, maar faalden. Met als gevolg dat een geautomatiseerd proces (een "evil proxy") van de cybercrimineel, met die onrechtmatig verkregen inloggegevens, ogenblikkelijk inlogde op https://circleci.com/ - waarbij deze verifieerder die geen onderscheid zag tussen het inloggen door echte account-eigenaren en de cybercrimineel.

Met andere woorden: als jij ergens "authenticeert", moet je de verifieerder kunnen vertrouwen dat deze niet, met het jou verstrekte bewijs van identiteit, als zijnde jou, elders "authenticeert". Dat risico bestaat bijvoorbeeld ook als je jouw wachtwoord hergebruikt; bijvoorbeeld een foute beheerder kan jouw inloggegevens "afluisteren" en daarmee proberen op andere sites proberen in te loggen, als zijnde jou.

Wat hier fout gaat, met in dit geval klanten als slachtoffer, is dat slachtoffers onvoldoende middelen hebben om nep van echt te onderscheiden - waarbij iedereen naar elkaar wijst als het gaat om oplossingen en er niets gebeurt. Sterker, de voorstanders dan DV (Domain Validated) certificaten blijven roepen dat deze een prima idee zijn, en Big-Tech Google (in https://www.chromium.org/Home/chromium-security/root-ca-policy/moving-forward-together/) er recentelijk voor pleitte om de levensduur van alle https servercertificaten in te korten tot 90 dagen, en om geheel te stoppen met revocation checks. Dit is niet omdat Google het beste voorheeft met internetgebruikers, maar omdat zij, om kosten te besparen, processen zoveel mogelijk wil automatiseren en de risico's naar internetters verplaatst.

Nb. dit gaat lijnrecht in tegen de eis van de EU om QWAC's (Qualified Website Authentication Certificate) te verplichten voor kritische websites, zoals waar je middels eIDAS en later met jouw EDIW (European Digital Identity Wallet) op moet "authenticeren". Voor DigiD is tegenwoordig een DV-certificaat ook "goed genoeg" terwijl de makers van webbrowsers er m.i. véél te weinig aan om gebruikers te helpen op dit punt.

Alle dreigingen (voor zover ik ze nu overzie)
De huidige definitie van authenticatie houdt m.i. onvoldoende of geen rekening met alle impersonatiedreigingen tijdens zo'n proces. Die dreiging is namelijk niet uitsluitend dat iemand niet is wie die entiteit claimt te zijn. In elk geval zijn dat, bij elk authenticatieproces (hier is X de primaire entiteit wiens identiteit wordt geverifieerd, voorbeelden eronder toon ik als "quote"):

1) Hoe zeker is het dat de geclaimde X niet de echte X is?

2) In hoeverre mogen echte verifieerders van elke X verwachten dat deze valse van echte verifieerders kan onderscheiden?

3) Transactiebeperkende metadata
Denkbaar is dat X transactiebeperkende metadata heeft bijgesloten, zoals het moment (datum en exacte tijdstip) dat X dienst identiteit aantoont, de reden waarvoor, bij een betaling het bedrag, uniek identificerende gegevens van de doelpartij en eventueel een uniek transactienummer: hoe moeilijk is het dan voor een AitM om deze te verwijderen en/of te wijzigen, zodanig dat de verifieerder niet van een vervalsing uitgaat?

4) Welke invloed hebben mogelijke belangen van alle betrokken stakeholders op het authenticatieproces?
Betrouwbare authenticatie is vaak wél in het belang van de betrokkene, juist omdat impersonatie haar of hem geld kan kosten en/of veel andere ellende kan opleveren (zoals bij de 71-jarige in het voorbeeld bovenaan deze pagina). Maar als jij zonder vervoersbewijs in het OV wordt aangehouden, is dat betrouwbare authenticatie niet in jouw belang.
Betrouwbare authenticatie is vaak niet in het belang van verifieerders, omdat dit veel geld kost en niet zij de grootste risico's lopen. Precies daarom vinden "moderne" banken een kopietje-paspoort goed genoeg voor het openen van een bankrekening.

Discussie
Of een schilderij authentiek is of een vervalsing, kan heel lastig vast te stellen zijn: hoe beter de imitator, hoe moeilijker dit is. Ik vind dat we authenticatie van entiteiten in datzelfde licht moeten zien, omdat er -vooral t.g.v. digitalisering- steeds meer slachtoffers vallen door impersonatie, met vaak ernstige gevolgen, en waarbij die slachtoffers het vaak "zelf mogen uitzoeken".

Een voorbeeld hiervan werd afgelopen weekend beschreven door de journaliste Avery Hartmans (die het zelf overkwam, en waar zij zelf helemaal niets aan kon doen) in https://www.businessinsider.com/credit-card-phone-theft-sim-swap-identity-theft-investigation-2023-4. In het kort werd haar nieuwe creditcard door criminele post-medewerkers onderschept, waarna de daders via een SIM-swap aanval haar het leven heel zuur maakten, de politie niets kon en wilde doen en zij bijna $10.000 dreigde kwijt te raken doordat haar bank ervan overtuigd raakte dat zij loog. Dankzij haar doorzettingsvermogen en vaardigheden heeft zij, zo te zien, haar eigen schade flink kunnen beperken.

Zorgvuldige en betrouwbare authenticatie is vaak arbeidsintensief en sowieso duur. Commerciële partijen, maar ook overheden, bezuinigen maar al te graag, verplaatsen hun risico's naar klanten en burgers en leggen de bewijslast bij hen.

Relatieve authenticatie werkt offline best goed. Denk aan iemand die je regelmatig tegenkomt in de kroeg, in het OV of tijdens het sporten: zonder dat je precies hoeft te weten om wie het exact gaat (de achternaam ken je soms zelfs niet), kun je daar een vertrouwensband mee opbouwen omdat je zo iemand herkent; daar hoef je nooit een paspoort voor te zien.

Online is relatieve authenticatie meestal onbetrouwbaar door relatief eenvoudig uit te voeren AitM-aanvallen (sterke MFA kan het aanvallers veel moeilijker maken, maar bijna niemand gebruikt ze en bovendien zijn vaak downgrade attacks naar AitM-kwetsbare authenticatie mogelijk). Sowieso moet je op de een of andere manier ruiken dat digid.nl (of een DigiD app) van de Rijksoverheid is, en dat het heel stom is om in te loggen op iets als mijndigid.nl (*) (of mijn-digid.nl, of dig-id.nl). Voor de zekerheid kun je (niet in alle webbrowsers) controleren aan wie het https servercertificaat voor zo'n website is toegekend; voor digid.nl is dat "Logius, 's-Gravenhage, Zuid-Holland, NL" (dat dit niet klinkt als "Rijksoverheid" zal wel weer aan mij liggen).

(*) mijndigid.nl is te koop voor 1750 USD bij SEDO Parking (waarbij ik niet uitsluit dat Justitie de verkopende partij is).

Absolute authenticatie: offline vindt dit plaats doordat iemand een identiteitsbewijs van jou op echtheid en geldigheid inspecteert, én verifieert dat jouw "verschijning" overeenkomt met de pasfoto en tekstuele informatie op het identiteitsbewijs. Uit https://nl.wikipedia.org/wiki/Authenticatie:

Online is absolute authenticatie veel minder betrouwbaar, sowieso doordat de verifieerder de betrokkene niet live ziet en het om reeksen bytes gaat die een AitM kan doorgeven aan een echte site, en zo als de betrokkene kan authenticeren.

Een enigszins ludiek voorbeeld is Monica Lewinsky (destijds een vriendinnetje van voormalig president Bill Clinton) die afgelopen week in https://twitter.com/MonicaLewinsky/status/1639972616210632708 klaagde dat ook andere accounts op Twitter zichzelf "Monica Lewinsky" mogen noemen, en notabene een man daar een blauw vinkje voor heeft kunnen kopen.

Dit is exact hetzelfde probleem als we zien bij e-mailafzenders: een echte naam is zelden een uniek identificerend gegeven van een persoon, en bovendien kan iedereen liegen dat zij of hij zo heet!

Als je, net als op Twitter, niet naar de wél noodzakelijkerwijs unieke accountnaam kijkt (@MonicaLewinsky op Twitter), weet je sowieso niet om wélke "Monica Lewinsky" het gaat. Maar als je dat wél doet, weet je hooguit enigszins zeker dat het om hetzelfde account gaat als waarvan je mogelijk eerder tweets hebt gelezen - waarvan de eigenaar niet echt Monica Lewinsky hoeft te heten. Enigszins, want haar (? of zijn, of bij een bot: het) account kan gehacked zijn en zijn overgenomen door een ander (dit overkwam ook Twitter CEO Jack Dorsey in 2019, via "SIM-swapping": https://security.nl/posting/623190 - en daar bleef het allesbehalve bij, zie bijvoorbeeld https://security.nl/posting/664553).

Met andere woorden, bijvoorbeeld bij e-mail kunt je nóg zo je best doen met SPF, DKIM, DMARC, ARC en wat nog meer: als de ontvanger niet het SMTP afzenderadres checkt helpt dat allemaal sowieso geen zier. En als de ontvanger wél het SMTP afzenderadres checkt (wat in een aantal e-mailclients zeer lastig is), weet de ontvanger nog steeds niet zeker dat de kennelijke afzender is wie zij/hij claimt te zijn, omdat:

1) sender@exampIe.com niet dezelfde is als sender@example.com (grote i versus kleine L), en zo zijn er vaak veel meer manipulaties van domeinnamen mogelijk, zoals cjib-online.nl of cjib.nI;

2) Je er meestal geen idee van hebt welke technische verificaties (SPF etc.) er tussen verzender en ontvanger zijn uitgevoerd;

3) Je niet weet (zeker bij een nieuw contact) of het SMTP afzenderadres daadwerkelijk van de kennelijke afzender is. Bijvoorbeeld draakje864@hotmail.jeweetwel zegt natuurlijk helemaal niets, maar MonicaLewinsky@hotmail.jeweetwel zegt ook niets: je hebt geen idee of dat account in het bezit is van iemand die écht Monica Lewinsky heet, en mocht dat zo zijn, om wélke Monica Lewensky het gaat.

4) Je niet weet of het e-mailaccount gehacked is (vaak aangeduid met BEC voor Business EmailCompromise).

Techsolutionlisten roepen vaak dat je die problemen kunt oplossen met PGP (en GnuPG etc.) of MIME certificaten, maar dat is onjuist omdat, i.r.t. PGP het authenticatieprobleem wordt verplaatst naar van wie een publieke sleutel is (die vaak gewoon wordt gemaild; een bijkomend probleem is dat de meeste mensen niets begrijpen van asymmetrische cryptografie) en er absurd zwakke MIME certificaten worden uitgegeven (DV-achtig, je krijgt een certificaat als je toegang hebt tot een e-mailaccount), waardoor beide "oplossingen" alleen maar tot schijnveiligheid leiden.

Conclusie
Als authenticatie beperkt blijft tot het verifiëren van het "bezit" van een weinigzeggend uniek identificerend gegeven, blijft misleiding en fraude eenvoudig. Echter, éénzijdig sterke authenticatie is flauwekul - sterke authenticatie is namelijk ook afhankelijk van de betrouwbaarheid van de verifiërende partij, en dus op z'n minst van het betrouwbaar kunnen vaststellen van diens identiteit. Het is ongelofelijk naïef om steeds meer kritische impersonatiegevoelige authenticatie te verplaatsen van offline naar "op afstand" (online, maar ook per telefoon of peer papieren post). Dit is de kat op het spek binden, met vaak "zwakkere" slachtoffers als gevolg, die maar moeten afwachten of zij geloofd, geholpen en gecompenseerd worden. En met een verdere tweedeling van de samenleving als gevolg: zij die niet kunnen, niet willen of voor hun eigen veiligheid niet mee zouden moeten doen, vallen buiten de boot.

P.S.
Vanaf 1 uur na plaatsing kan ik deze post niet meer wijzigen. Kijk hieronder voor aanvullingen en correcties die ik post, al dan niet na comments van andere bezoekers van security.nl.