Passkeys zijn een val. Gebruik ze niet.

Het lijkt erop dat elke website wil dat we stoppen met het gebruik van wachtwoorden. Er is een vervanger die we wordt aangeraden te gebruiken: passkeys. Dit zou enigszins zorgwekkend moeten zijn als wachtwoorden vertrouwd bij je zijn en je deze vage passkeys niet volledig begrijpt.

Websites beweren dat passkeys veiliger of handiger zijn, of iets anders dat voordelig klinkt. Hoewel het waar is dat passkeys veel veiliger kunnen zijn dan wachtwoorden, en inderdaad handiger kunnen zijn, is dat niet het hele verhaal. Passkeys zijn niet ontworpen om jouw belangen prioriteit te geven. Net als het Trojaanse paard zijn passkeys aan de oppervlakte legitiem elegant, maar schuilt er iets verontrustends binnenin.

Wat belangrijk is om te weten, is dat je in tegenstelling tot elk ander type inloggegevens geen ultieme controle hebt over je passkeys. Bij wachtwoorden kun je zelf kiezen waar je ze opschrijft; bij authenticator-apps kun je zelf beslissen welke je gebruikt (ze zijn grotendeels uitwisselbaar); en fysieke beveiligingssleutels kun je aan een collega geven als je die echt vertrouwt. Maar bij passkeys zit een verborgen knop waarmee de websites waarop je ze gebruikt, geleidelijk je vermogen kunnen wegnemen om ermee te doen wat jij wilt.

Ik zal verderop uitleggen hoe dat mogelijk is, maar laten we eerst kijken naar wie wil dat je passkeys gebruikt.

De FIDO Alliantie

Passkeys zijn een uitvinding van de FIDO Alliantie[1], een consortium van verschillende concurrerende belangen: Big Tech, kleine techbedrijven, nationale overheden, inlichtingendiensten, banken, diverse openbare instellingen en zelfs een handvol non-profitorganisaties zoals Mozilla. Zij zijn het er allemaal over eens dat passkeys een goed en rechtvaardig doel dienen.

De leden van de FIDO Alliantie hebben elk hun eigen belangen:

• Big Tech wil kleine ongemakken in ons leven brengen zodat ze ons meer advertenties kunnen verkopen.
• Inlichtingendiensten willen iedereen ter wereld kunnen volgen.
• Banken willen vrij zijn van schadevergoedingen.
• Kleine techbedrijven willen goedkope oplossingen om aansprakelijkheid te verminderen.
• Mozilla wil voorkomen dat ze voor een specifiek standpunt moeten sterven[2].

Ik beweer niet dat dit slechte motivaties zijn. Maar het is opvallend dat geen enkele consumentenorganisatie lid is van de FIDO Alliantie. Dit staat in contrast met bijvoorbeeld het World Wide Web Consortium (W3C), de organisatie die de standaarden voor het web bepaalt. Naast de gebruikelijke zakelijke leden heeft het W3C niet alleen publieke belangengroepen, maar ook universiteiten en Tim Berners-Lee, de Britse informaticus die in 1989 het World Wide Web uitvond. Bij de FIDO Alliantie is niemand aanwezig om een sterk pleidooi te houden voor de belangen van de gebruiker.

De onveiligheid van wachtwoorden

De reden die aan het publiek wordt gepresenteerd voor het gebruik van passkeys is dat wachtwoorden onveilig zijn. Op dit punt ben ik het eens. Denk aan de servers van het Amerikaanse IT-bedrijf SolarWinds, waarvan bleek dat ze het wachtwoord solarwinds123 gebruikten. De Emergency Management Agency van Hawaï onthulde per ongeluk een wachtwoord via een plaknotitie op iemands bureau op de achtergrond van een foto. Als je beveiliging afhangt van een wachtwoord, zul je altijd bang zijn dat iemand, ergens, op een manier heeft ontdekt wat het is en al toegang heeft tot je bankrekening.

Aan de andere kant: wat wachtwoorden voor hen heeft spreken is dat ze zeer intuïtief zijn, iedereen weet hoe ze werken, mensen gebruiken ze al sinds mensenheugenissen, en je kunt zelf kiezen waar je ze bewaart en met wie je ze deelt. (Houd overigens in gedachten dat Netflix niet wil dat je je wachtwoorden deelt.)

Superieure alternatieven: TOTP

Er bestaan al beveiligingsmechanismen die superieur zijn aan wachtwoorden, maar de FIDO Alliantie lijkt deze te negeren. Eerst was er tweestapsverificatie (2FA, in het bijzonder: het ontvangen van een sms of e-mail met een eenmalige code), en later kwam het robuustere systeem van Time-Based One-Time Passwords (TOTP) – in de volksmond "authenticator-apps".

Wat handig is aan TOTP is dat het helemaal niet vertrouwt op sms, e-mail of zelfs het internet. Je authenticator-software genereert simpelweg elke 30 seconden een willekeurig ogend nummer op basis van de huidige tijd (en een willekeurig startnummer, genaamd een "seed" of "key", dat uniek is voor jou). Dit is alles wat een website nodig heeft om te verifiëren dat jij het bent.

De term "authenticator-app" is misleidend, omdat websites vaak suggereren dat je een specifieke app moet downloaden, zoals Google Authenticator. In werkelijkheid is er een open standaard voor TOTP (RFC 6238). De formule die wordt gebruikt om deze nummers te genereren is publieke kennis; je hoeft dus geen specifieke software te gebruiken. Je hebt niet eens een smartphone nodig; je kunt je laptop of zelfs een Game Boy[3] uit de jaren 90 hiervoor gebruiken. Je kunt elke software en hardware gebruiken die redelijk de tijd kan bijhouden en een paar regels code kan verwerken. Je kunt de software zelfs zelf schrijven in Python, of een LLM laten schrijven.

TOTP is een geweldige oplossing. Als je per ongeluk je TOTP-code lekt op een foto van je bureau, loop je slechts een paar minuten risico tot de code verloopt. TOTP is minder intuïtief dan wachtwoorden, maar net als bij wachtwoorden kun je zelf kiezen hoe je ze bewaart en welke software je gebruikt. Je kunt niet gemakkelijk je eigen voet dwarszitten met een makkelijk te raden code zoals wachtwoord123, want alle TOTP-codes zijn even moeilijk te raden. Bovendien kun je een code naar een vriend sturen zodat die tijdelijk op je Netflix-account kan inloggen terwijl je op zakenreis bent. Je kunt zelfs je TOTP-seed delen, zodat je vrienden zelf codes kunnen genereren. Deze data is van jou en jij bepaalt hoe je ermee omgaat. Open standaarden zijn prachtig.

(Netflix wil overigens ook niet dat je je TOTP-sleutels deelt.)

Wat maakt passkeys anders?

Op het eerste gezicht lijken passkeys erg op TOTP. Beiden hebben een open standaard (RFC 6238 voor TOTP, WebAuthn voor passkeys). In theorie zouden passkeys dus dezelfde mooie eigenschappen moeten hebben. Ik heb zelf een passkey gegenereerd met vrije opensourcesoftware en deze per e-mail naar een vriend gestuurd; nu kunnen we beiden met die passkey op dezelfde website komen. Ik hoefde niemand om toestemming te vragen. Bovendien hoef ik geen nummers handmatig in te typen of magische woorden te onthouden. Op basis daarvan is een passkey inderdaad handig.

(Maar Netflix wil niet dat je je passkeys deelt.)

De addertje onder het gras

Het probleem is dat er iets anders is dat ook een "passkey" wordt genoemd, en dat is totaal niet zoals het type dat ik zojuist beschreef. Er zijn veel verschillende dingen die "passkeys" worden genoemd, en de FIDO Alliantie heeft ze bewust allemaal dezelfde naam gegeven. Ik geloof dat dit is gedaan om gebruikers bewust in verwarring te brengen en hen te ontmoedigen om te nauwkeurig naar de kleine lettertjes te kijken.

In de technische documentatie van de WebAuthn-standaard wordt de term "passkey" nauwelijks gebruikt. In plaats daarvan is er sprake van:

• Discoverable en undiscoverable credentials;
• Hardware-backed en software-backed credentials;
• Attested en unattested credentials.

Er zijn zoveel optionele componenten dat de specificaties meer lezen als een onderdelencatalogus dan als een standaard. Laten we bekijken wat er in die catalogus staat.

Kopieerbaar vs. Niet-kopieerbaar

Beide soorten bestaan. Een passkey kan zo worden gemaakt dat hij niet gekopieerd kan worden. Dit is handig voor de gebruiker om zeker te weten dat niemand anders toegang heeft tot het account zolang de iPhone in je zak zit. Aan de andere kant kunnen passkeys kopieerbaar zijn, zodat je één sleutel tussen je apparaten kunt delen.

Overdraagbaar vs. Niet-overdraagbaar

Beide soorten bestaan. Verrassend genoeg kan een passkey die niet-kopieerbaar is, nog steeds overdraagbaar zijn. Dit betekent dat wanneer je iets naar een vriend stuurt, het van je eigen apparaat verdwijnt. Je wilt misschien een niet-overdraagbare sleutel om absoluut zeker te weten dat fysiek bezit van één specifiek apparaat vereist is voor toegang. Of je wilt een overdraagbare sleutel zodat hij mee kan verhuizen wanneer je je smartphone vervangt door het model van volgend jaar.

Hardware-backed vs. Software-backed

Beide soorten bestaan. Passkeys kunnen bestanden zijn, maar ze kunnen dat ook niet zijn. Als passkeys altijd bestanden zouden moeten zijn, zou het onduidelijk zijn hoe iemand een niet-kopieerbare passkey kan maken.

Hardware-backed passkeys maken gebruik van een beveiligde chip in moderne apparaten die data kan opslaan die niet geëxtraheerd kan worden (de data kan de chip niet verlaten). Dit worden "cryptoprocessors" genoemd (zoals de Trusted Platform Module in laptops of de Secure Enclave in iPhones). Deze chips zijn zeer veilig; ze maken gebruik van chemische en elektronische detectiemaatregelen en vernietigen zichzelf als je probeert de data fysiek te extraheren[5]. Niemand kan de geheime data uit je cryptoprocessor halen: niet Netflix, niet je besturingssysteem, en zelfs jijzelf niet.

Software-backed keys gebruik je als je begrijpt hoe bestanden werken en al een oplossing hebt voor het opslaan van je privégegevens.

User-Present vs. Non-User-Present

Beide soorten bestaan. Sommige passkeys vereisen dat iemand op een knop drukt of een prompt bevestigt. Andere kunnen worden gebruikt zonder dat er iemand in het proces betrokken is. Dat laatste is handig als je software wilt machtigen om namens jou te handelen.

User-Verified vs. Non-User-Verified

Beide soorten bestaan. Passkeys kunnen optioneel biometrie vereisen (vingerafdrukken, retina-scans) of het gebruik van pincodes/wachtwoorden om extra zeker te zijn van de identiteit van de gebruiker.

Attested vs. Non-Attested

Hier gaat het mis. De FIDO Alliantie heeft de standaard zo gedefinieerd dat je passkey-software aan de dienst die je bezoekt moet doorgeven welke van bovenstaande functies zijn ingeschakeld. Dit worden authenticator data flags genoemd[6].

Dit betekent dat Twitter (X) kan zeggen: "Sorry, we accepteren hier alleen de User-Present User-Verified Non-Copyable Hardware-Backed varianten van passkeys." Ze zullen dit waarschijnlijk verpakken als: "Helaas is je passkey niet veilig genoeg; download onze app."

Kun je niet gewoon je eigen software schrijven die liegt over deze functies? Ja, dat kan, behalve bij Attested passkeys[7].

Attested passkeys maken gebruik van remote attestation om cryptografisch te verifiëren – via de tamper-proof cryptoprocessor – dat je een van de goedgekeurde passkey-beheerders gebruikt, en niet een eigen programma dat kan liegen. Dit is de functie waardoor jij niet langer zelf beslist over je passkeys.

Remote attestation vereist de medewerking van je cryptoprocessor, je passkey-software, het besturingssysteem van je apparaat en de firmware. Als één van deze zaken faalt – bijvoorbeeld omdat je telefoon geen beveiligingsupdates meer krijgt en je een aangepast besturingssysteem zoals LineageOS hebt geïnstalleerd om veilig te blijven zonder een nieuwe telefoon te kopen – dan kan Twitter (X) dit merken en je blokkeren.

Er zijn legitieme redenen voor remote attestation, zoals bescherming tegen frauduleuze passkey-apps. Maar er zijn ook redenen om het niet te willen: je wilt misschien software gebruiken die Twitter niet goedkeurt, zoals Linux, of een telefoon met een gereviseerd besturingssysteem. (Of, als je kwaadaardig bent, wil je liegen tegen Netflix dat jij en je drie vrienden dezelfde persoon zijn op hetzelfde apparaat.)

(Met attestation kan Netflix eindelijk voorkomen dat je je passkeys deelt.)

Meer dan alleen Netflix of Twitter

Er is genoeg reden om aarzelend te zijn voordat je een passkey instelt. Passkeys zijn ontworpen om op de achtergrond te functioneren zonder dat je de details ziet. Mijn verwachting is dat de industrie begint met weinig beperkingen, en deze geleidelijk toevoegt. Over een paar jaar zullen mensen vergeten dat ze ooit een keuze hadden in welke beveiligingsmaatregelen ze wilden activeren.

De meeste mensen gebruiken Windows, Android, macOS of iOS. Zij zullen nooit merken dat hun apparaat een remote attestation-check faalt, omdat ze gewoon een nieuwe telefoon kopen als de updates stoppen.

Maar waarom zouden inlichtingendiensten of bedrijven als Microsoft en Google om dit geven? Ik denk dat ze een ander motief hebben: ze kunnen passkeys gebruiken om te voorkomen dat je niet-goedgekeurde software draait. Remote attestation stelt hen in staat te verifiëren of je apparaat bijvoorbeeld niet in staat is om versleutelde berichten te versturen, een app van een concurrent te draaien, of sociale media te gebruiken zonder je ID te verifiëren.

Ik hecht waarde aan het zelf kunnen beslissen welke software ik gebruik. Ik gebruik extensies in mijn browser om websites aan te passen: video's die automatisch afspelen blokkeren, opdringerige advertenties filteren of de "aanbevolen video's" van YouTube uitschakelen. Google bezit Chrome en kan de ondersteuning voor deze extensies verwijderen (zoals ze deden met uBlock Origin); met remote attestation kunnen ze me zelfs verhinderen om een andere browser te gebruiken die dat niet doet.

In eerdere revisies van de FIDO-standaard (WebAuthn Level 1 en 2) waren er minder opties. In 2022 voegde de FIDO Alliantie meer opties toe (Level 3), zodat websites kunnen weten of je gegevens kopieerbaar zijn. Er zijn nog twee flags "gereserveerd voor toekomstig gebruik". Wat zullen onze passkeys in de toekomst van ons vereisen?

Als je geeft om je privacy en die van anderen, en gelooft dat mensen vrij moeten zijn om te kiezen welke software er op hun apparaten draait, dan vraag ik je om deze tientallen verschillende beveiligingsmechanismen, die allemaal verwarrend als "passkeys" worden gebrand, af te wijzen. Wacht op iets dat net zo handig en veilig is, maar duidelijker gedefinieerd is en minder voorwaarden heeft. In de tussentijd kan je Game Boy je voorzien van TOTP[10].

***

Voetnoten

1. Geen relatie met het Canadese mobiele netwerk met dezelfde naam.
2. Mozilla heeft de reputatie om tegen iets te vechten en uiteindelijk toch toe te geven, zoals bij de implementatie van het propriëtaire Widevine DRM-systeem van Google in de verder open-source Firefox-browser.
3. Er is daadwerkelijk iemand TOTP voor de Game Boy gemaakt.
4. In de praktijk kan een hardware-backed key ook een bestandcomponent hebben, maar deze is cryptografisch nutteloos zonder de bijbehorende cryptoprocessor.
5. Consumentenapparaten wissen zichzelf meestal elektronisch, maar er zijn geruchten over creatievere boobytraps; XEROX maakte ooit een chip die in kleine scherven uiteenviel als beveiligingsmaatregel.
6. De authenticator data flags komen niet exact overeen met de functies in dit artikel, maar komen in de buurt. Bijvoorbeeld: UP is User-Present, UV is User-Verified en BE is Copyability ("Backup-Eligible").
7. Authenticator data flag AT.
8. Remote attestation kan in principe ook omgekeerd worden uitgevoerd, om te verifiëren dat de server waarmee je verbindt niets doet wat je niet wilt. Tot mijn weten heeft geen enkel groot platform dit geïmplementeerd.
9. "User-Verified" vereist dat "User Present" is ingesteld. In de praktijk zijn er echter willekeurig veel passkey-beperkingen mogelijk met WebAuthn.
10. Addendum: Passkeys hebben fantastische eigenschappen, zoals het feit dat ze domain-bound zijn (resistent tegen Man-In-The-Middle aanvallen). Het is jammer dat de FIDO Alliantie een goed product heeft verpest door remote attestation toe te voegen. Voor wie de hoge beveiliging van passkeys wil zonder de beperkingen: gebruik fysieke beveiligingssleutels zoals een YubiKey. Omdat deze zelfstandig zijn, hoeven de attestation-vereisten niet je volledige besturingssysteem te vergrendelen.