Naast de vendor lock-in snap ik ook niet dat een passkey als een 2FA methode kan worden gezien. Waarom zou mijn username/wachtwoord in een password manager dat dan niet zijn? De passkey is niets meer dan een ingewikkeld wachtwoord.

Ik kan je geruststellen wat betreft vendor lock-in:
zowel voor als na je dood zul je een lock-in met de belastingdienst hebben.

Vendor lock-in is een keuze.
Geen tekortkoming van het fenomeen passkey. Maar beleid van de door jouw gekozen gijzelnemer.

Enneh, een passkey is echt wèl iets meer dan slechts een statisch ingewikkeld wachtwoord.

Ja in ieder geval niet kwantumproof; en waar is die 2e factor dan?

Je kan ongemak bij het verliezen van je device voorkomen door de passkeys in de cloud op te slaan. Net als bij BitLocker, daar zit de sleutel in de TPM chip en in de cloud van Microsoft.

Met deze oplossing kan je ook bij je passkey als je meerdere devices gebruikt om dezelfde website te bezoeken. Bijvoorbeeld een PC en een smartphone.

Altijd weer iemand die zijn persoonlijke superspeciale situatie als norm neemt en dan roept "eigenlijk hetzelfde" .

passkeys zijn typisch enorm lang genoeg, random gegenereerd, niet gedeeld met andere services, en zelfs niet gedeeld met andere devices.
Allemaal erg wenselijke eigenschappen die het overgrote deel van de eindgebruikers met een password niet weet te bereiken.,
Misschien jij en nog een paar wel.

"maar ikke kan wel goed omgaan met passwords dus daarom is password based login helemaal OK en moet gewoon aan blijven overal"

Niet kwantumproof ? Wat een onzin . symmetrische encryptie heeft, qua kwamtum risico hooguit een 2n key nodig . (AES256 ofzo).

Voor zo ver quantum computing uberhaupt enig risico is betreft dat alleen de bekende public key algorithmen als RSA en DH.

Afgelopen maart trapte Troy Hunt in een phishing-mail en logde (met 2FA/MFA) in op een nepwebsite. Uit https://www.troyhunt.com/a-sneaky-phish-just-grabbed-my-mailchimp-mailing-list/:

Wat hier fout ging is dat Troy Hunt (een vaak aangehaalde tegenstander van EV-certificaten):

• Dacht dat de websitenaam mailchimp—sso.com óók van de eigenaren van mailchimp.com was, en

• De melding van zijn wachtwoordmanager, dat deze geen record had voor mailchimp—sso.com negeerde en handmatig het record voor mailchimp.com opzocht, en

• Hijzelf fatsoenlijke certificaten heeft helpen slopen waardoor hij dáár niet uit kon halen dat mailchimp—sso.com niet van dezelfde eigenaren als van mailchimp.com was.

De nepwebsite https://mailchimp—sso.com is een AitM (Attacker in the Middle), ook bekend als een proxy (plaatsvervanger of stand-in). De nepsite werkt als een kabel en geeft alles (beide kanten op) dóór - totdat de AitM heeft bereikt wat hij/zij wilde bereiken.

Hieronder is te zien hoe Troy Hunt zijn inloggegevens (hier fictief) onbedoeld invult op https://mailchimp—sso.com, in plaats van op https://mailchimp.com, namelijk:

User-ID: troy@serv.tld
Wachtwoord: 3*f7G!sQ'z#
2FA/MFA Authenticator code: 620753

Te zien is dat de nepsite de inloggegevens meteen doorstuurt naar de echte site. Omdat die gegevens kloppen verklaart de echte site de aanmelder voor ingelogd, en stuurt een session cookie terug (via de https verbinding van mailchimp—sso.com naar mailchimp.com). De nepsite lijkt nu, richting Troy Hunt, te "hangen". Ondertussen vraagt de AitM de hele klantendatabase op.


Als Troy Hunt een passkey zou hebben voor mailchimp.com, en hij zou proberen om daarmee in te loggen op mailchimp—sso.com, dan zoekt de browser in de passkey-database naar mailchimp—sso.com - en vindt hoogstwaarschijnlijk niks, wat leidt tot een foutmelding.

In tegenstelling tot wat Troy Hunt deed (handmatig zoeken naar mailchimp.com in zijn 1Password wachtwoordmanager), staat een passkey-manager "handmatig zoeken" niet toe. Bovendien moet er bij WebAuthn sprake zijn van een foutloze https-verbinding; vervolgens is de in de adresbalk getoonde domeinnaam waar de browser naar zoekt in de database van de passkey-manager (niet exact, zie hieronder).

De check op de juiste domeinnaam is verdeeld in twee stappen. In https://github.com/w3ctag/design-reviews/issues/97#issuecomment-175766580 is te zien wat het probleem kan zijn.

1) In de database van de passkey-manager wordt de hoofddomeinnaam opgenomen (voor deze website zou dat security.nl zijn, en als je bijv. op myaccount.google.com een passkey zou aanmaken, zal google.com in de database van de passkey manager worden opgenomen. Daarmee kun je dan ook inloggen op bijvoorbeeld https://accounts.sandbox.google.com (okay), maar in principe ook op https://sites.google.com en op https://firebase.google.com. Dat laatste wil je beslist niet, want daar staat content van derden (pagina's aldaar zouden in principe als passkey-AitM's misbruikt kunnen worden).

2) Tijdens inloggen maakt de browser een "pakketje" met allerlei gegevens, waaronder de volledige domeinnaam van de website waarop m.b.v. WebAuthn wordt ingelogd. Dat pakketje wordt digitaal ondertekend met de private key behorend bij de passkey (of FIDO2 hardware key) die is gekoppeld aan de hoofddomeinmaam.

Nadat de browser dat pakketje naar de server heeft gestuurd, checkt die server, m.b.v. de public key, of de digitale handtekening onder het pakketje geldig is (dit bewijst dat de browser toegang had tot de WebAuthn private key voor dit account). Vervolgens is het de taak van de server om te checken of inloggen op de specifieke subdomeinnaam is toegestaan.

Een niet te onderschatten risico is dat de uiteindelijke authenticatieserver hier niet zorgvuldig op checkt, en bijv. dat een niet meer gebruikte domeinnaam naar een IP-adres blijft verwijzen en de server daarachter in verkeerde handen valt (want dan is een WebAuthn-AitM een eitje).

Als er géén sprake is van:

• Het vorige punt (subdomeinnaam hijack);

• Een website met een gegeven websitenaam (domeinnaam) die onterecht een geldig certificaat heeft verkregen (bijv. doordat een DNS-record door een kwaadwillende is gewijzigd of middels een BGP-hijack);

• De client niet is gecompromitteerd,

is phishing (middels een AitM nepwebsite) bij het inloggen gebruikmakend van WebAuthn onmogelijk.

WebAuthn is dus niet volledig phishing-bestendig. Phishing-resistant, waarbij dat laatste als "weerstand biedend" of "moeilijk makend" wordt gelezen ("resistent" is mij te absoluut) vind ik correct.


1) De allerbelangrijkste eigenschap van WebAuthn is dat, tijdens inloggen, software in plaats van de PEBCAK checkt of de juiste website geopend is;

2) Als je de asymmetrische crypto wegdenkt, vormt een fatsoenlijk (random) gegenereerde en nooit hergebruikte public key een nagenoeg perfect wachtwoord;

3) WebAuthn prijzen om asymmetrische cryptografie is grotendeels snake oil. Hoewel het extreem lastig kan zijn om WebAuthn private keys te stelen, zijn er verschillende andere manieren om met WebAuthn beschermde accounts over te nemen (zoals een aanvaller die een WebAuthn public key van hem/haar toevoegt aan jouw account op de server, of jouw public key vervangt);

4) Ook het kraken van WebAuthn asymmetrische sleutelparen is een broodje aap. Immers, WebAuthn public keys zijn helemaal niet public (niet zoals in certificaten en bij PGP). Zo'n public key wordt (éénmalig) overgedragen naar een server via een https-verbinding. Als een aanvaller toegang krijgt tot jouw public key op de server, is het allesbehalve jouw grootste zorg dat zij/hij daaruit jouw private key af zal proberen te leiden (zie ook het vorige punt);

5) 2FA/MFA is meestal een hoax omdat een session cookie 1FA is;

6) 2FA/MFA is meestal een hoax omdat de uitgifte van DV-certificaten 1FA is;

7) Passkeys zijn dus hooguit 2FA/MFA op jouw device(s). Maar onder iOS/iPadOS is zelfs dat, onder bepaalde omstandigheden, niet het geval (zie onder "iOS, iPadOS en Android passkeys zijn een PUINHOOP" in https://security.nl/posting/905537 en daarvoor, onder "(1) iPhone/iPad zonder vingerafdruk", in https://security.nl/posting/905377);

8) Je kunt zelf vaak geen backup maken van de volledige records (inclusief private keys) in passkey managers (laat staan van FIDO2 hardware keys);

9) Daardoor is het verlies van toegang tot jouw passkey private keys relatief groot, vergroot door onduidelijkheden zoals bij Android (zie "Android" in https://security.nl/posting/905377);

10) Daardoor zijn alternatieve (rescue) inlogmethodes noodzakelijk die zelden phishing-resistant zijn;

11) Risico vendor-lock-in;

12) Fratsen zoals "passkey sharing" van Apple verzwakken het concept.

Red flag!
Red flag.

Nee dus. Key lokaal en nergens anders. Dat is de enige plek waar je het zelf onder controle hebt.


Kortom: Ja, het heeft voordelen. Organisatorisch is het best een risico.

Je privatekey (het gene wat je zelf in bezit hebt, al dan niet op een specifiek apparaat) is je tweede factor.

Voor de gebruiker zou het op deze manier zeker niet overzichtelijk blijven.

Het is een manier om gebruikers nog afhankelijker te maken van digitale processen die ze zelf niet begrijpen. What can go wrong?

Ik hou het graag bij mijn eigen wachtwoord, dat ik onthoud/bewaar op een manier die ik hier niet aan de grote klok ga hangen. In ieder geval niet in de cloud.

Bedacht door nerd, handig voor nerds & voor big tech. Maar niet veilig voor gewone stervelingen.

Dat is nog steeds maar 1 factor. Waarschijnlijk gaat men ervan uit dat je deze moet unlocken met een wachtwoord oid, maar dat is afhankelijk van de client side implementatie. Het kan net zo goed werken zonder addtioneel password. Dus om te stellen dat passkeys 2FA impliceren is te kort door de bocht.

Symetrische envryptier is inderdaad niet gevoelig voor kwantum.. Maar laten passkeys nu werken met asymetrische key pairs. Zie ook https://bitwarden.com/blog/how-do-passkeys-work/.