Stabiele Chrome-versie krijgt ondersteuning voor op FIDO gebaseerde passkeys

Chrome-gebruikers op Windows 11, macOS en Android kunnen met de Stable M108-update passkeys gebruiken om zonder wachtwoord in te loggen op sites. Passkeys werken met het FIDO-protocol en gebruiken bijvoorbeeld de vingerafdrukscanner van smartphones.

Na het inloggen op een website krijgen Chrome-gebruikers de vraag of ze een passkey willen aanmaken voor die site. Bij het aanmaken van de passkey vraagt het apparaat de gebruiker zich op dezelfde manier te authenticeren als wanneer de gebruiker het apparaat ontgrendelt. Bij een smartphone of laptop kan dit bijvoorbeeld met de vingerafdrukscanner, schrijft Google.

Als gebruikers zo'n passkey hebben aangemaakt, kunnen ze bij volgende inlogpogingen die passkey gebruiken om in te loggen en hoeven ze het wachtwoord niet meer in te vullen. Desktopgebruikers kunnen ook inloggen met een passkey van een mobiele telefoon, door het gebruik van QR-codes. Gebruikers kunnen hun passkeys binnen de Windows- en macOS-versies van Chrome beheren.

Voordat passkeys werken, moeten websitebeheerders ondersteuning toevoegen door middel van een WebAuthn-api. Google zegt verder passkeys naar meer apparaten te willen brengen, zoals iOS- en Chrome OS-apparaten. Ook andere bedrijven, zoals Microsoft en Apple, werken aan wachtwoordloze FIDO-authenticatie.

Reacties (56)

Wellicht zijn er tweakers geïnteresseerd in mijn reactie op security.nl over dit onderwerp, die ik hieronder (iets aangepast) herhaal.

Vooraf: het onderstaande is voor zover ik weet. Ik heb er veel over gelezen maar nog nauwelijks praktijkervaring mee.

M.b.t. de beveiliging van private keys (als onderdeel van passkeys): de bedoeling is dat de private keys uitsluitend in onversleutelde toestand zijn in door hardware beschermde "secure enclaves" op apparaten van eindgebruikers. In die zin is het verschil met een FIDO2 hardware key (zoals Yubikey, Feitian, Google Titan etc.) klein.

Een belangrijk verschil met hardware keys is dat een set credentials (jouw passkeys voor één of meer accounts) kunnen worden gebackupped - mits het platform dat ondersteunt; ze kunnen dan versleuteld geëxporteerd worden uit de secure hardware enclave, en kunnen ook weer (in versleutelde vorm) worden gerestored - waarna ze in de secure hardware enclave worden ontsleuteld.

Met andere woorden, een cloud-account kan worden gebruikt voor zowel backuppen als synchroniseren naar meerdere apparaten. De voorwaarden daarvoor zijn dat elk apparaat ook een voldoende veilige secure enclave heeft (waar jij toegang tot hebt), jij het wachtwoord kent waarmee de credentials zijn versleuteld - en toegang hebt tot het cloud-account.

Bij Apple devices plus Apple software (met name Safari) lijkt dit het soepelst te werken; als je dezelfde toegangscode gebruikt op elk van jouw Apple devices, en apparaten+OS niet te oud zijn, en je op elk apparaat hetzelfde Apple ID (Apple cloud-account o.a. voor iCloud) hebt geconfigureerd, is het de bedoeling dat jouw passkeys automatisch worden gesynchroniseerd tussen jouw apparaten. Daarbij zijn (in elk geval de private keys) uitsluitend onversleuteld in secure enclaves (waar de meeste, zo niet alle, apps geen toegang tot hebben).

Dit is natuurlijk wel vette vendor lock-in, want je kunt Apple "secrets" (waaronder passkeys) niet synchroniseren naar andere besturingssystemen zoals Android, Windows of Linux. Dus als je begint aan ofwel Apple ofwel Google passkeys, is het extra vervelend om over te stappen naar een ander platform (zeker op het moment dat je maar één device hebt en je de toegang daartoe verliest door verlies, diefstal of defectraken). Dus hoewel je passkeys, in tegenstelling tot credentials in hardware keys, wel kunt backuppen, zijn er nog steeds flinke beperkingen.

De bedoeling is namelijk dat jij nooit zelf toegang hebt tot jouw private keys, en dus ook kwaadaardige software niet. Echter, software die jij gebruikt moet wel informatie (o.a. een "nonce", een lang random getal, verzonden door de server) digitaal kunnen laten ondertekenen (in de secure enclave) met de juiste private key, om te bewijzen dat die private key aanwezig is op het apparaat waarmee je authenticeert. Als de gebruikte software kwaadaardig is, of als het apparaat op andere wijze is gecompromitteerd, kun je niet uitsluiten dat malware toegang krijgt tot één of meer van jouw accounts; ook passkeys gaan je niet redden bij een "client compromise".

M.b.t. die vendor lock-in: het wachten is natuurlijk op hacks waarmee je zelf (met jouw apparaat-toegangscode en Apple-ID wachtwoord + 2FA) de in iCloud versleuteld gebackupte "secrets" kunt downloaden en ontsleutelen - maar of dat ooit gaat lukken en wanneer, weet ik niet. En zodra zo'n hack bestaat kan malware daar natuurlijk ook gebruik van maken.

Apple heeft trouwens wel iets controversieels geïntroduceerd: "passkey sharing". Daarmee kun je jouw "secrets" delen met iemand anders - mits die ander ook een (ondersteund) Apple device heeft.

Ten slotte heeft 1Password ook een soort passkeys aangekondigd, door hen "Universal Sign On" genoemd. Omdat zij stellen elk OS te ondersteunen, vermoed ik dat de private keys niet in alle gevallen in secure hardware enclaves zullen zitten, wat diefstal zou kunnen vereenvoudigen (maar dat is niet anders dan bij wachtwoorden in een "gewone" wachtwoordmanager zoals KeePass of de huidige 1Password). De vraag is echter of alle websites passkeys, met potentieel minder veilig opgeslagen private keys, zullen ondersteunen. Tijdens inloggen kunnen websites (via WebAuthn) opvragen hoe veilig de private key is opgeslagen, bijvoorbeeld "non-exportable" op een FIDO2 hardware key.

Passkeys klinken mooi maar er zijn nogal wat haken en ogen (en ik heb hierboven nog niet alle risico's benoemd die ik ken).

Ik vind het allemaal een beetje complex om te begrijpen. Zou je kunnen zeggen dat een passkey een soort master password is die is opgeslagen in de secure enclave, en dat onder dat master password voor elke site een uniek wachtwoord zit, en dat deze wachtwoorden geheel automatisch worden ingevuld, en opgestuurd nadat de secure enclave hiervoor toestemming heeft (d.m.v. de authenticatiemethode die je op je telefoon hebt ingesteld)?

Hoe het zit met het master password weet ik niet goed. Maar wel dat FIDO in principe zonder passwords werkt.

Per website wordt er een public/private keypair aangemaakt.

Bij registratie op een site deel je de publieke sleutel.

Bij inloggen teken je digitaal de "challenge" die je van de website krijgt en die zij dan weer kunnen controleren met de publieke sleutel.

[Reactie gewijzigd door cire op 10 december 2022 12:27]

Door Redsandro:

Zou je kunnen zeggen dat een passkey een soort master password is die is opgeslagen in de secure enclave, [...]

Geen master password: sterk vereenvoudigd is een passkey gewoon een uniek, lang en niet te raden wachtwoord voor één online account - echter met de volgende 2 m.i. belangrijkste verschillen:

1) De kans dat je op een nepsite inlogt is véél kleiner, omdat de software checkt of de domeinnaam van de server hetzelfde is als waar jij ooit jouw account op aanmaakte;

2) Je hebt geen eigen beheer meer over jouw inloggegevens.

Dat was de korte uitleg. Voor geïnteresseerden leg ik hieronder (zo compact als ik kan, maar toch heel lang) uit hoe asymmetrische cryptografie, passkeys en certificaten werken (mede om het authenticeren met passkeys te kunnen vergelijken met client certificaten).

Nb. feitelijk bevatten FIDO2 hardware keys gewoon één of meer passkeys; beide systemen gebruiken hetzelde WebAuthn protocol. Ik laat hier overigens veel details, waaronder attestation, weg.

Asymmetrische cryptografie
Digitale certificaten werken met "asymmetrische sleutelparen" waarbij elk paar bestaat uit een private key (die je strikt geheim houdt) en een public key die je met iedereen kunt delen (waarbij vaak vergeten of niet gesnapt wordt dat het loeibelangrijk is, om bedrog te voorkomen, dat je zeker weet van wie een public key is).

Door een wiskundige truc geldt (er zijn veel mitsen en maren, maar de essentie is):

1) Wat je met de public key versleutelt, kun je uitsluitend met de bijpassende private key ontsleutelen;

en vice versa:

2) Wat je met de private key versleutelt, kun je uitsluitend met de bijpassende public key ontsleutelen.

Digitale handtekeningen
De genoemde tweede toepassing is de basis van digitale handtekeningen: in theorie versleutel je bijvoorbeeld een koopakte met jouw private key. Iedereen die jouw public key heeft kan die versleutelde koopakte dan ontsleutelen. Als zij zeker weten dat de public key van jou is én dat niemand anders jouw private key heeft, moet deze koopakte impliciet door jou zijn ondertekend.

In de praktijk werken digitale handtekeningen iets anders: je berekent een cryptografische hash over het te ondertekenen document (bijv. een digitale koopakte, effectief een reeks bytes). Vervolgens versleutel je die cryptografische hash met jouw private key. De digitale handtekening bestaat dan uit de (met de private key) versleutelde cryptografische hash, die samen met het (onversleutelde) document wordt verzonden.

Om de digitale handtekening te kunnen controleren moet de ontvanger over een public key beschikken en zeker weten dat die public key van de verzender is (daarover zo meer).

Dan doet de ontvanger:
a) ontsleutel de versleutelde cryptografische hash met de public key van de ondertekenaar;
b) bereken zelf de cryptografische hash over het document;
c) als beide cryptografische hashes identiek zijn, klopt de (bijgevoegde) digitale handtekening.

Van WIE is die pubkey?
Hoe weet je nu zeker van wie een public key is (d.w.z. wie de bijbehorende private key bezit)? Dat kan met een digitaal certificaat.

Digitale certificaten
De public key wordt, samen met informatie die uniek de eigenaar van het sleutelpaar beschrijft (bijv. een e-mailadres of een domeinnaam zoals "tweakers.net" bij een https servercertificaat) met allerlei metadata (waaronder geldigheidsduur en gebruiksdoel) opgenomen in een "certificaatverzoek".

Cert-uitgever: trusted third party
Nadat een certificaatuitgever heeft vastgesteld dat de public key daadwerkelijk van de vermelde eigenaar is, zet die certificaatuitgever een digitale handtekening onder dat certificaatverzoek, waarmee het verzoek een certificaat is geworden.

Effectief koppelt een certificaat een public key aan een unieke identiteitsbeschrijving.

Aanvulling 20221211 11:12: het bezitten en kunnen "tonen" (verzenden) van een certificaat (of losse public key) zegt niets over de identiteit van de verzender. Bij elke transactie hoort tevens het bezit van de bijpassende private key te worden aangetoond (op een manier die niet kwetsbaar is voor replay-attacks).

Van WIE is die pubkey? #2
Indien jij (d.w.z. de software die jij gebruikt) als ontvanger die certificaatuitgever vertrouwt, en zeker weet dat het certificaat echt door de kennelijke certificaatuitgever is ondertekend en jij erop vertrouwt dat die certificaatuitgever z'n werk goed doet, weet je dus van wie de public key in dat certificaat is.

WebAuthn: passkeys en FIDO2
WebAuthn (gebruikt door FIDO2 hardware keys en passkeys) werkt ook met asymmetrische sleutelparen, maar zonder dat daar certificaten bij worden gebruikt. Als er een public key aan jouw account wordt toegevoegd, heeft de server geen bewijs dat die public key van jou is (een aanvaller met toegang tot jouw account kan dus ook zijn public key toevoegen en jou buitensluiten).

Daarmee zijn passkeys vooral geschikt voor consumenten. Client certificaten kunnen door werkgevers worden verstrekt, bijv. in smartcards of USB devices. Met client certs heb je een soort "absolute" authenticatie, terwijl je met WebAuthn een pseudoniem account kunt aanmaken (zoals velen doen op tweakers, en hoewel ik echt Erik van Straten heet, heb ik dat nergens bewezen - los van welke Erik van Straten ik ben - ik heb naamgenoten).

Passkey account maken
Aanmaken van een account met passkey gaat op vergelijkbare wijze als met een wachtwoord, en toevoegen van een passkey aan een bestaand account kun je vergelijken met het toevoegen van een gangbare 2FA methode. Ik ga hier niet verder in op de details.

Inloggen met passkey
Bij inloggen heeft een passkey twee belangrijke voordelen:

1) De software (server + client) checkt, redelijk betrouwbaar (veel betrouwbaarder dan veel mensen doen, maar iets minder betrouwbaar dan kan met een client certificaat) of de in de adresbalk van jouw browser getoonde domeinnaam van de door jou bedoelde server is (waar je ooit het account hebt aangemaakt). Daarmee is het voor aanvallers veel lastiger om mensen te foppen met "evil proxy" aanvallen, meestal met "lijkt-op" domeinnamen zoals
microsoft-sso.net of
accounts-google.com (hoe die "evil proxy" aanvallen werken, leg ik hier uit).

Daarmee zijn passkeys aanzienlijk veiliger dan andere vormen van MFA/2FA, zoals TOTP met "Authenticator" apps (ook number matching helpt niet tegen evil proxies!) en OTP (o.a. via SMS).

2) Nogal gehyped maar m.i. nauwelijks relevant als mensen per account een uniek wachtwoord zouden gebruiken: als de server gehacked wordt hebben de aanvallers bijna niets aan de public key van jouw passkey die op de server staat (wel hebben ze toegang tot al jouw data op die server, en dat is nou net wat we met inloggen proberen te verhinderen).

Werking van passkeys
Bij inloggen werkt een passkey, vereenvoudigd, als volgt:

a) Om te laten weten wie er wil inloggen, stuur jij een identifier (vaak jouw e-mailadres) naar de server.

b) De server zoekt de gegevens van jouw account op, en als je een passkey wilt gebruiken, stuurt de server een "nonce" (een uniek lang, meestal willekeurig, getal) naar de client.

c) Voordat de client naar een passkey- (WebAuthn-) record voor de in de adresbalk van jouw browser getoonde domeinnaam mag zoeken in de secure enclave (of hardware key), moet je met biometrie of een pincode bewijzen dat jij niet iemand anders bent.

d) De client zoekt daarna in de secure enclave (of hardware key) naar een WebAuthn-record met een domeinnaam die gelijk is aan, of eindigt op (met een punt ertussen!), de domeinnaam in de adresbalk van de browser. Nb. dit is de éérste WebAuthn serverdomeinnaam-check.

Voorbeeld: als je een passkey hebt voor google.com, worden dus ook accounts.google.com en sites.google.com geaccepteerd - maar niet
accounts-google.com.

e) De client plakt de nonce en het in de adresbalk getoonde origin (https://domeinnaam:poortnummer waarbij ":poortnummer" optioneel is) achter elkaar, en zet daar (in de secure enclave of hardware key, met de private key uit het gevonden passkey-record) een digitale handtekening onder. Vervolgens stuurt de client dat pakketje ter authenticatie van jou naar de server.

f) De server checkt de digitale handtekening met de public key van jouw passkey in jouw accountgegevens (als die klopt weet de server dat jij de bijpassende private key hebt).

Belangrijk: de server hoort ook te controleren of de ontvangen nonce gelijk is aan de eerder door de server verzonden nonce (om "replay attacks" te voorkomen) én de server hoort te checken of jij met een passkey (of hardware key) daadwerkelijk mag inloggen op het meegestuurde origin (dit is de tweede check op de serverdomeinnaam).

Reden voor die tweede check: een aanvaller zou een evil proxy login pagina op sites.google.com kunnen maken en jou verleiden daarop in te loggen, waarmee die aanvaller vervolgens als jou kan inloggen op accounts.google.com.

Nb. ik heb persoonlijk contact gehad met Google om het beschreven scenario uit te sluiten; Google zegt hun inlogservers strikt te laten checken op welke subdomeinen je mag inloggen (dat zijn er overigens meerdere).

g) Als alles klopt stuurt de server een session-cookie naar jouw browser, waarmee je vanaf dat moment bij elke transactie (1FA!) authenticeert (tot je uitlogt of wordt uitgelogd).

Enkele WebAuthn risico's
Naast het risico dat servers niet goed op subdomeinen checken (denk aan subdomain-takeover attacks) valt en staat WebAuthn met de betrouwbaarheid van https servercertificaten. Als een MitM/AitM (Man/Attacker in the Middle), bijvoorbeeld via een DNS-record-hack of een BGP hijack een geldig certificaat kan verkrijgen, kan daarmee een "evil proxy" worden gecreëerd.

Bij client-certificaten bestaat dit AitM-risico niet (mits de server de juiste TLS-checks uitvoert). Het "nadeel" van client certs is dat geen enkele AitM is toegestaan: als firewalls en/of virusscanners "TLS-inspectie" op het inlogproces uitvoeren, slaagt dit niet (WebAuthn heeft hier dan weer geen last van).

Een ander risico is dat mensen, die nog geen passkey gebruiken, met phishing-aanvallen worden verleid om een passkey toe te voegen op een nepserver (evil proxy). De aanvaller logt dan onmiddelijk met de verstrekte inloggegevens (indien nodig inclusief TOTP of OTP) op de echte inlogserver en voegt daar desgewenst zijn eigen passkey toe (en/of wijzigt het wachtwoord). De public key van de door het slachtoffer aangemaakte passkey kan de aanvaller gewoon weggooien.

Nog een groot probleem: vaak bestaat de mogelijkheid om, als alternatief, met een phishable methode (evil proxy) in te loggen. Bijv. met een e-mail kan een aanvaller je naar een nepsite sturen waarop staat dat er een probleem is met jouw passkey of iets op de server, en je deze keer op alternatieve wijze moet inloggen.

Hier laat ik het maar even bij :-)

Aanvulling 20221210 14:28: in tegenstelling tot bij client-certificaten kun je WebAuthn credentials (passkeys in een gestolen smartphone of opgeslagen in een verloren hardware key) niet snel en eenvoudig intrekken (revoken, er bestaat geen revocation methode).

[Reactie gewijzigd door ErikvanStraten op 11 december 2022 11:12]

Ik ben hier helemáál geen fan van.

Het idee is juist dat je met 2FA twee verschillende authenticatiemethodes hebt. In essentie breng je dat hiermee terug naar één methode - namelijk een relatief onveilige telefoon of laptop. Je veiligheid is dus gebaseerd op een vrij eenvoudig te hacken apparaat dat constant aan het internet hangt. Het is ook nog eens bewust ontworpen om credentials te syncen naar andere apparaten! Sterker nog, als ik de FAQ goed lees, is het zelfs de bedoeling dat Google/Apple de credentials in de cloud opslaat. Vergeleken met wachtwoord+TOTP of wachtwoord+Yubikey lijkt dit dus een flinke achteruitgang te zijn.

En het probleem is dat dergelijke ideeën niet vrijwillig blijven: DigiD is voor veel dingen al overgegaan naar authenticatie met alléén de DigiD-app - die is beschermd met een 5-cijferige pincode. Hoe is dat veiliger dan mijn 50-karakter wachtwoord in een password locker en SMS 2FA?!

Het idee is juist dat je met 2FA twee verschillende authenticatiemethodes hebt. In essentie breng je dat hiermee terug naar één methode - namelijk een relatief onveilige telefoon of laptop.

De manier waarop dit werkt is certificate-based. Je logt met een cryptografisch gegenereerde one-time code in. Deze wordt gegenereerd in de FIDO authenticator zelf; en die authenticator is het enige stukje apparaat wat beschikking heeft over de meestersleutel.

Effectief is er geen herbruikbare sleutel om te jatten die direct aan software in het OS blootgesteld staat. Om dat voor elkaar te krijgen zou je de key vault van de authenticator moeten kunnen plunderen. Dwz de secure enclave v/d telefoon; de TPM in een PC of laptop; of de insteek USB hardware-key.

Je veiligheid is dus gebaseerd op een vrij eenvoudig te hacken apparaat dat constant aan het internet hangt. Het is ook nog eens bewust ontworpen om credentials te syncen naar andere apparaten! Sterker nog, als ik de FAQ goed lees, is het zelfs de bedoeling dat Google/Apple de credentials in de cloud opslaat.

Dat kan dus alleen als je gebruik maakt van een software authenticator in het OS. Stille hint dat hier geen officiële ondersteuning voor is binnen de FIDO protocollen: verschillende OS-vendors moeten dit zelf voor hun eigen implementaties in hun eigen OS opzetten, en het is niet per definitie overzetbaar tussen verschillende OSen van verschillende makelij.

Vergeleken met wachtwoord+TOTP of wachtwoord+Yubikey lijkt dit dus een flinke achteruitgang te zijn.

Je kunt dit dus ook gewoon met een FIDO-compatible Yubikey gebruiken als authenticator...

[Reactie gewijzigd door R4gnax op 9 december 2022 16:11]

De manier waarop dit werkt is certificate-based. Je logt met een cryptografisch gegenereerde one-time code in. Deze wordt gegenereerd in de FIDO authenticator zelf; en die authenticator is het enige stukje apparaat wat beschikking heeft over de meestersleutel.

Zeker, hier heb ik geen enkele kritiek op. Het concept van FIDO is solide, vooral omdat de website zich ook moet identificeren naar de authenticator toe. Maar dat is alsnog slechts één factor - namelijk "iets dat je hebt".

Effectief is er geen herbruikbare sleutel om te jatten die direct aan software in the OS blootgesteld staat. Om dat voor elkaar te krijgen zou je de key vault van de authenticator moeten kunnen plunderen. Dwz de secure enclave v/d telefoon; de TPM in een PC of laptop; of de insteek USB hardware-key.

In de praktijk valt dit flink tegen. Veel Android smartphones hebben geen secure enclave maar een Trusted Execution Environment - wat in essentie niets meer is dan een virtuele machine die naast het OS zelf draait op dezelfde CPU. Apple's Secure Element is al meerdere malen gecracked, en het zal voor Android niet veel anders zijn.

Ook ben je compleet afhankelijk van het OS van de smartphone of laptop: als/wanneer hier een bug in zit, kan een aanvaller dit gewoon MitMen. Een apparaat met arbitrair uitvoerbare code dat toegankelijk is vanaf het internet gebruiken als authenticater is gewoon geen goed idee.

Dat kan dus alleen als je gebruik maakt van een software authenticator in het OS. Stille hint dat hier geen officiële ondersteuning voor is binnen de FIDO protocollen: verschillende OS-vendors moeten dit zelf voor hun eigen implementaties in hun eigen OS opzetten, en het is niet per definitie overzetbaar tussen verschillende OSen van verschillende makelij.

Nee, dat kan ook met een hardware authenticator. Zie Apple's website: "Because passkeys are synced with iCloud Keychain, they’re available across Apple devices."

Je kunt dit dus ook gewoon met een FIDO-compatible Yubikey gebruiken als authenticator...

Uiteraard. Maar hiermee normaliseren ze het gebruik van onveilige authenticator-implementaties, en gooien ze ook nog eens het concept van 2FA de deur uit. Het zou veel beter zijn om Yubikeys te promoten en wachtwoord+Yubikey als beveiliging te houden.

Nee, dat kan ook met een hardware authenticator. Zie Apple's website: "Because passkeys are synced with iCloud Keychain, they’re available across Apple devices."

Ik zie het nergens expliciet staan.

Als je de default Apple authenticator met FaceID of TouchID gebruikt; dan gebruik je de OS software authenticator en niet een losse hardware authenticator. En laat nou die hele PR pagina opgezet zijn met in het achterhoofd het FaceID / TouchID smaakje...

Ik heb geen Apple-apparatuur, maar is het niet zo dat TouchID (en eventueel ook FaceID) juist gebruik maakt van de securityhardware binnen het apparaat? Op Windows gaat Windows Hello bijvoorbeeld via de TPM, ik kan me niet voorstellen dat Apple dat ook niet doet.

Dan heb je alsnog gewoon de tweede factor, je moet namelijk een key uit de TPM van je fysieke apparaat krijgen want die kopieer je niet zonder de hele apparaat uit elkaar te halen.

Het zou veel beter zijn om Yubikeys te promoten en wachtwoord+Yubikey als beveiliging te houden.

Het zou veel beter zijn om FIDO-compatible hardware keys te promoten, ipv één specifiek merk.

Helemaal eens!

Helaas zijn ze door het hergebruik van FIDO voor Secure Enclaves / software authenticators dat label aan het vergiftigen - hierdoor is het lastig om een leek te vertellen om een "FIDO key" te nemen.

De Yubikey is een vrij goed beschikbare en betrouwbare FIDO hardware key met een acceptabele prijs, en daardoor een veilige optie om aan te raden. Maar een key van Feitian of een andere concurrent is natuurlijk net zo goed.

Plus dat je als website kan zien welke authenticator merk en type er is gebruikt.
Dus je kan, als DIGID/andere belangrijke website of alleen website delen, onveilige/type authenticator weigeren.

R4gnax schreef:

De manier waarop dit werkt is certificate-based. Je logt met een cryptografisch gegenereerde one-time code in. Deze wordt gegenereerd in de FIDO authenticator zelf; en die authenticator is het enige stukje apparaat wat beschikking heeft over de meestersleutel.

Dat is niet helemaal juist, mogelijk dat je client certificaten verwart met WebAuthn.

In deze (lange) post leg ik uit hoe ik denk dat passkeys werken en wat het verschil is met client certificaten.

Dat is niet helemaal juist, mogelijk dat je client certificaten verwart met WebAuthn.

Nee; maar ik wilde niet te diep in detail treden voor een one-off post.
Jouw relaas is inderdaad het volledige in-depth verhaal 'zoals 't heurt'

De pincode is alleen de vergrendeling van de app op de telefoon en gekoppeld aan je device dacht ik. Je moet dus én de pincode én het device hebben.

Wat betreft SMS 2fa: https://www.youtube.com/watch?v=lc7scxvKQOo

Interessante video, maar hoe heeft het betrekking op SMS 2FA?

2e simkaart aanvragen en op laten sturen? Gebeurd helaas te vaak.

Zeker, SMS 2FA staat qua veiligheid redelijk onderaan de ladder.

Maar smartphones zijn niet bijzonder veilig, en ik heb er bijzonder weinig vertrouwen in dat ze onkraakbaar zijn. Een flink deel van de populatie loopt rond met een smartphone die al jaren geen updates meer krijgt. Het is een kwestie van tijd voor er een wijdverspreide aanval komt.

Een vijfcijferige pincode is niet bijzonder veel waard zonder dat hier hardwarematige verificatie achter zit, zoals bij een pinpas. Als je het in software doet, is het in een mum van tijd te kraken - in software is het onmogelijk om na X opties het op slot te zetten. Daarnaast zullen veel mensen bij een zelfgekozen pincode gewoon hun geboortedatum of dergelijk makkelijke nummers gebruiken. In de praktijk komt het er dus op neer dat je alleen het apparaat nodig hebt - of met een beetje pech alleen een internetverbinding naar het apparaat toe.

Het idee is juist dat je met 2FA twee verschillende authenticatiemethodes hebt

Niet volgens de standaard definitie: een authentication factor is "something you know/have/are". Je laptop/telefoon is "have", om het key material te unlocken moet je biometrie ("are") of een wachtwoord/PIN/swipe pattern ("know") gebruiken, het is dus 2FA.

Sterker nog, als ik de FAQ goed lees, is het zelfs de bedoeling dat Google/Apple de credentials in de cloud opslaat.

End-to-end encrypted ja, maar aangezien password managers zoals BitWarden en 1Password hebben al aangekondigd ook passkeys te zullen ondersteunen zal een offline-only optie vanzelf komen als die niet al bestaat.

Vergeleken met wachtwoord+TOTP of wachtwoord+Yubikey lijkt dit dus een flinke achteruitgang te zijn.

Je vergelijkt nu 2FA met 2FA maar als je meet langs andere dimensies is wachtwoord+TOTP beduidend minder sterk dan passkeys of wachtwoord+externe FIDO authenticator:
- FIDO is phishing resistant
- FIDO keys zijn uniek per registratie, dus geen credential stuffing mogelijk

Passkeys zijn een gebruiksvriendelijke manier om het threat model van "hack één database en krijg toegang tot accounts van vele mensen" naar "hack een device en krijg toegang tot accounts van de eigenaar" en dat is een mooie stap vooruit voor de gemiddelde internetgebruiker - die beduidend minder technisch is dan een gemiddelde bezoeker van Tweakers.

Voor de mensen/bedrijven waar de security-lat zo hoog liggen dat je de combi OS/TEE en/of cloud-sync niet kan vertrouwen blijven oplossingen zoals Yubikeys of FIDO-capable smartcards bestaan.

Niet volgens de standaard definitie: een authentication factor is "something you know/have/are". Je laptop/telefoon is "have", om het key material te unlocken moet je biometrie ("are") of een wachtwoord/PIN/swipe pattern ("know") gebruiken, het is dus 2FA.

Die definitie klopt, maar in dit geval is de biometrie en wachtwoord/pin/swipe pattern 100% client-side. Vingerafdrukken laat je achter op je telefoon, en swipe-patterns met je vette vingers ook. Face-scans zijn vaak te foppen met een foto, of een slapend persoon.
Als alternatief kan je het ook bruteforcen, want een PIN of swipe-pattern heeft praktisch nul beveiliging. Zat mensen die bijvoorbeeld gewoon hun geboortedatum als PIN gebruiken, en een lockout na X pogingen is vrij triviaal te omzeilen.

Het hele idee hiervan is juist dat je geen moeilijk wachtwoord hoeft te onthouden. In de praktijk is dit dus slechts één factor, namelijk "something you have"

End-to-end encrypted ja, maar aangezien password managers zoals BitWarden en 1Password hebben al aangekondigd ook passkeys te zullen ondersteunen zal een offline-only optie vanzelf komen als die niet al bestaat.

Is het daadwerkelijk "end-to-end encrypted"? Google zegt zelf bijvoorbeeld "In some cases, for example, when the older device was lost or damaged, users may need to recover the end-to-end encryption keys from a secure online backup". Het is per definitie onmogelijk om in zo'n geval te recoveren als ze écht end-to-end encryption gebruiken, dus ze spreken zichzelf tegen.

Je vergelijkt nu 2FA met 2FA maar als je meet langs andere dimensies is wachtwoord+TOTP beduidend minder sterk dan passkeys of wachtwoord+externe FIDO authenticator:
- FIDO is phishing resistant
- FIDO keys zijn uniek per registratie, dus geen credential stuffing mogelijk

Ik tel Passkeys maar als één factor, vanwege die hierboven beschreven redenen. Wachtwoord+TOTP is inderdaad minder sterk op het vlak van phishing, maar in plaats daarvan heeft een ieder met fysieke toegang tot je telefoon of laptop nu ineens relatief eenvoudig toegang tot ál je accounts. Dat beschouw ik niet als verbetering.

Passkeys zijn een gebruiksvriendelijke manier om het threat model van "hack één database en krijg toegang tot accounts van vele mensen" naar "hack een device en krijg toegang tot accounts van de eigenaar" en dat is een mooie stap vooruit voor de gemiddelde internetgebruiker - die beduidend minder technisch is dan een gemiddelde bezoeker van Tweakers.

"Hack één database" is al jaren geen serieus probleem meer.

Ik ben het er mee eens dat het potentieel een goed idee is, en het is een stuk eenvoudiger dan iedereen aan de Yubikeys krijgen. Maar waarom schoppen we ineens wachtwoorden de deur uit? Waarom niet gewoon én wachtwoord én passkeys als 2FA?

Die definitie klopt, maar [...] In de praktijk is dit dus slechts één factor, namelijk "something you have"

Nee, two factor blijft two factor, full stop. De definitie die je beschrijft staat bekend als 'assurance', en afhankelijk van de eisen die jij (of je organisatie) stellen kan je de hogere assurance van een externe USB authenticator (die niet in de cloud gesynct wordt) verkiezen boven een passkey op iOS of Android. Zie ook volgende punt:

Is het daadwerkelijk "end-to-end encrypted"? [...] Het is per definitie onmogelijk om in zo'n geval te recoveren als ze écht end-to-end encryption gebruiken, dus ze spreken zichzelf tegen.

Ik ben niet bekend met Google's implementatie, maar op eerste gezicht de beschrijving die je geeft klinkt als Apple's escrow voor recovery. End-to-end encryptie is niet per definitie incompatible met recovery, er gebeurt een stuk meer onder de kap dan alleen "sla sleutel veilig in een speciaal chipje op".

maar in plaats daarvan heeft een ieder met fysieke toegang tot je telefoon of laptop nu ineens relatief eenvoudig toegang tot ál je accounts. Dat beschouw ik niet als verbetering.

WebAuthn gebruikt dezelfde local security mechanismes op iOS en Android als Apple/Google Pay. "Relatief eenvoudig" valt mee gezien de jaren dat dit al goed gaat.

Terug naar WebAuthn: in een wereld waar de meeste mensen niet erg technisch/security minded zijn, en dus: zwakke wachtwoorden gebruiken (op meerdere sites), alleen 2FA indien gedwongen (maar dan het liefst SMS ipv 'moeilijke app'), makkelijk in phishing trappen... zijn passkeys een forse stap vooruit qua security posture voor deze mensen, en aantrekkelijk omdat het gebruiksvriendelijker is:
- Per-site public keys, dus geen credential stuffing of password spraying meer
- Phishing proof dankzij de browser-implementatie en random challenges per login poging
- Sneller en makkelijker dankzij biometrie (geen problemen met bereik, vertraagde SMS delivery, typefouten, clock sync issues met TOTP, etc)

"Hack één database" is al jaren geen serieus probleem meer.

https://haveibeenpwned.com/ krijgt nog steeds nieuwe data? Welke garantie heb jij dat een willekeurige server uberhaupt je wachtwoord fatsoenlijk opslaat met bcrypt/Argon2? Met public-key crypto weet je ten minste dat de public key nutteloos is indien gelekt (en als dat niet meer waar is, heeft het internet een veel groter probleem dan jouw account ergens).

Waarom niet gewoon én wachtwoord én passkeys als 2FA?

Omdat een statisch stukje low-entropy data praktisch niets toevoegt in een systeem waar public key cryptography gebruikt wordt tussen client en server. Jouw bezwaren lijken met name op gebied van lokale authenticatie te zijn om het key material te unlocken voor deze communicatie. Twee opties:
- harden je telefoon in om alleen een alfanumeriek wachtwoord te accepteren, zichzelf te wissen na x foute inlogpogingen, etc
- registreer minimaal twee security keys bij elke dienst

Dit is dus een compleet softwarematige implementatie van WebAuthn/FIDO2 op devices(met internet connectie welteverstaan). Ik gebruik zelf FIDO2/WebAuthn (wanneer mogelijk) met een hardwarematige key.
Maar compleet in software....daar lijkt me toch e.e.a op aan te merken of niet?

Het is niet volledig softwarematig. De keys worden (als het goed is) opgeslagen op een Trusted Platform Module, hardware die is ontworpen om veilig keys te kunnen opslaan.

In het screenshot hier kan je zien dat er staat:

These passkeys are stored in Windows Hello on this computer. They aren't saved to your Google Account

Windows Hello gebruikt van vervolgens weer een TPM chip voor de beveiliging:

Backed by a Trusted Platform Module (TPM) chip,...

Dat klopt, TPM is in principe prima waarvoor het bedoeld is, maar doorgaans wordt TPM(of iets TPM achtigs) ingezet op momenten dat er geen netwerk en/of internet is, b.v. tijdens het booten van Windows(bitlocker key) of tijdens een lockscreen waarbij het device in feite onbruikbaar is.
Maar dit is anders aangezien(tenzij ik het verkeerd begrijp) "alles" te initiëren valt vanuit een gebruikerssessie op het device zelf.
Een losse hardwarematige key vereist een fysieke ingreep om hem te laten werken, en dát maakt het net secure.

Edit: TLDR: Wat ik me dus eigenlijk afvraag, is die fingerprint unlock van TPM(die vervolgens de keys vrijgeeft) net zo veilig als een extern FIDO2 device.

[Reactie gewijzigd door YoMarK op 9 december 2022 16:02]

Qua user attestation: Nee.
Op alle andere vlakken? Praktisch gezien 'ja.'

Malware moet heel diep in je OS zitten om herbruikbare keys te onderscheppen.
Op niveau v/h OS is praktisch alles een one-time key.

[Reactie gewijzigd door R4gnax op 9 december 2022 16:23]

Ik zie in ieder geval meer attack surface dan bij een USB-stick die in m'n broekzak zit.
Verder ben ik me er ook wel van bewust dat dit waarschijnlijk veiliger is dan andere (MFA) oplossingen als password+2e factor in de vorm van SMS, TOTP, push(Microsoft Authenicator), maar toch...ik heb toch m'n bedenkingen of FIDO2/webauthm in het algemeen hiermee niet "gedowngrade" wordt. Want dat staat nu te boek als praktisch niet-hackable in combinatie met een hardware key.

Ik denk dat je helemaal gelijk hebt dat een normale security-key een stuk veiliger is dan FIDO.

Ik denk alleen ook dat de gemiddelde gebruiker geen 2FA-sleutel heeft. De gemiddelde gebruiker heeft daarentegen wel een smartphone. Op deze manier kan de beveiliging van je account significant verbeterd worden met hardware die je als gebruiker al hebt.

Voor écht kritieke beveiligingsopties kun je beter speciale hardware gebruiken maar de 2FA van de meeste websites kan prima op deze manier.

Aannemende dat Apple/Google/Microsoft zich aan de WebAuthn-standaard houden, kan de websitebeheerder ook bepaalde eisen stellen aan de sleutel. Zo kan er worden gekozen tussen een platform of een roaming authenticator (spec) waarmee een sleutel tot één apparaat of tot meerdere apparaten kan worden toegewezen. Ook kan het transport worden gespecificeerd; je hebt als ontwikkelaar de keuze uit NFC, Bluetooth, USB, hybride (smartphone + computer) of intern. Als een website écht veiligheid wil forceren kan deze ervoor kiezen hun WebAuthn niet compatibel te maken met FIDO en strengere eisen te stellen. Dit kan heel ver gaan, in het verleden waren er bijvoorbeeld websites die alleen werkten met Yubikey-authenticators.

Persoonlijk acht ik WebAuthn met bevestiging van de gebruiker als eerste factor veiliger dan een wachtwoord, zelfs met FIDO. Als je zover komt dat je de FIDO-sleutel kan laten communiceren met een service, zit je al diep genoeg in hun besturingssysteem en accounts je ook gewoon bij iemand's mail inloggen voor de resetemail. Veilige wachtwoorden onthouden kunnen mensen niet en wachtwoordbeheerders zijn voor mensen te moeilijk dus een oplossing waar voor de meeste mensen een enkel veilig wachtwoord met 2FA alle andere identiteiten beheert lijkt me de beveiliging alleen maar goed doen.

Dan moet ik wel zeggen dat ik me niet zo goed voel bij deze directe koppeling aan een Apple/Google/Microsoft-account. Als je permanent verbannen wordt omdat je naaktfoto's van kinderen op je drive hebt, zoals die kinderarts van een aantal jaar terug, wil je wel bij je andere services kunnen blijven komen. Een FIDO-systeem dat ik niet zelf kan hosten (of waar ik niet een extern bedrijf voor kan betalen) vind ik niet betrouwbaar.

Ik denk dat je helemaal gelijk hebt dat een normale security-key een stuk veiliger is dan FIDO.

Veiliger dan FIDO passkeys; ja.
Maar je weet dat FIDO breder is dan alleen passkeys; dat blijkt uit je verdere bericht.
En bijv. FIDO U2F - het iets oudere broertje - implementeert de protocollen die jij waarschijnlijk zou associëren met wat dan uit jouw mond, een normale security-key heet.

Ook kan het transport worden gespecificeerd; je hebt als ontwikkelaar de keuze uit NFC, Bluetooth, USB, hybride (smartphone + computer) of intern.

De mogelijke AuthenticatorTransport types zijn USB; NFC; Bluetooth LE, en het speciale "internal" type.
Jouw aangegeven "hybride" optie bestaat niet als transport type. Dat is simpelweg transport over BLE waar de telefoon middels Bluetooth met de laptop of PC gepaird wordt en als FIDO / WebAuthn compatible authenticator dienst doet voor de computer die als client een verzoek tot authenticatie vanuit de dienst - de zgn. relying party - (door)stuurt.

Technisch gezien kun je ook je compleet eigen platformgebonden transport definiëren en gebruiken. Het moet zich alleen aan de WebAuthn specificatie voor het abstract authenticator model houden. Dat is waar het "internal" transport hint voor dient.

Als een website écht veiligheid wil forceren kan deze ervoor kiezen hun WebAuthn niet compatibel te maken met FIDO en strengere eisen te stellen. Dit kan heel ver gaan, in het verleden waren er bijvoorbeeld websites die alleen werkten met Yubikey-authenticators.

Dat kan in elk geval niet op basis van het gegeven transport type. Want dat is enkel een vage hint en een best-effort schatting van de vorm van transport. Verder geeft de WebAuthn API enkel informatie prijs in gradatie van beveiling, zoals bijv. over het cryptografische algoritme dat er gebruikt wordt via een COSEAlgorithmIdentifier. De client - dwz de browser - geeft niet prijs a/d dienst - dwz. de relying party - wat er precies voor authenticator gebruikt wordt, enkel wat het veiligheidsniveau van bepaalde aspecten van die authenticator is. Een dienst heeft dus niet de mogelijkheid om specifieke implementaties te weren.

Dan moet ik wel zeggen dat ik me niet zo goed voel bij deze directe koppeling aan een Apple/Google/Microsoft-account. Als je permanent verbannen wordt omdat je naaktfoto's van kinderen op je drive hebt, zoals die kinderarts van een aantal jaar terug, wil je wel bij je andere services kunnen blijven komen. Een FIDO-systeem dat ik niet zelf kan hosten (of waar ik niet een extern bedrijf voor kan betalen) vind ik niet betrouwbaar.

Die koppeling is optioneel. Je kunt ook zelf een cross-platform authenticator gebruiken zoals een USB key. En relying parties die zich aan de specificatie houden moeten het vziw ook mogelijk maken om meerdere authenticators aan dezelfde account gekoppeld te hebben.

[Reactie gewijzigd door R4gnax op 9 december 2022 21:25]

Jouw aangegeven "hybride" optie bestaat niet als transport type

Dat is het wel, in elk geval in de spec die de techbedrijven nu implementeren (zie de editor's draft) de spec:

hybrid Indicates the respective authenticator can be contacted using a combination of (often separate) data-transport and proximity mechanisms. This supports, for example, authentication on a desktop computer using a smartphone.

Voorheen leek in elk geval Apple die "caBLE" te noemen als ik deze mensen mag geloven. Dit was al geïmplementeerd in browsers en hoewel de draft nog geen officiële spec is, is het wel een feature die de grote browsers ondersteunen.

Specifieke sleutels vereisen was vooral een ding in U2F maar met WebAuthn kan het nog steeds als je attestation op de juiste manier misbruikt. Het Chromium-team geeft aan dat websites die dit doen en zonder goede technische redenen hun attestation-lijst niet bijhouden de mogelijkheid om de API te gebruiken te ontnemen maar dat klinkt als iets dat pas na jaren zal gebeuren, als ze inderdaad daadwerkelijk ingrijpen.

De koppeling met de techgiganten is inderdaad optioneel maar het risico is dat alleen de standaardimplementatie van grote browsers ondersteund zal worden op dezelfde manier dat websites het technisch zouden moeten doen op Firefox maar dat vaak niet het geval is. Niet iedere browser en niet ieder stuk software implementeert dezelfde functies op dezelfde manier en het is erg makkelijk om (al dan niet per ongeluk) naar een wereld te werken waar je op bepaalde sites niet kan inloggen zonder een Apple/Google/Microsoft-account op dezelfde manier dat je in bepaalde landen nog steeds ActiveX nodig hebt om je bankzaken te doen en je nog steeds een recente versie van iOS of Android met Google Play Services nodig hebt voor dingen als bankzaken op je telefoon.

De API is compleet open maar tot de eerste zelfbestuurde FIDO-servers online verschijnen blijf ik huiverig. Wellicht kan Mozilla hun Persona-merk hiervoor inzetten en zich op die manier weer relevant maken, dat zou heel ik heel mooi vinden.

Cloud-assisted Bluetooth Low Energy (CaBLE) heet nu idd 'hybrid', en momenteel wordt nog in FIDO gewerkt aan de spec en dat is itt W3C niet publiek.

Het grote verschil met de bestaande BT transport is dat BT niet gebruikt wordt voor alle CTAP communicatie met de authenticator, maar alleen om de communicatie te bootstrappen en te bewijzen dat je fysiek in de buurt bent. In deze aflevering van de podcast Security. Cryptography. Whatever. wordt uitgelegd door Adam Langley van Google precies hoe het werkt, zich over tijd heeft ontwikkeld en wat de struikelblokken met 'gewone' Bluetooth zijn.

[Reactie gewijzigd door Rafe op 10 december 2022 21:35]

Dat is juist expliciet niet het doel.

Zie de white paper - het hele idee is om sleutels te hebben die het verliezen van je apparaat overleven. Het hele idee is dat het OS de sleutels opslaat in de cloud zodat ze op alle apparaten beschikbaar zijn - hierdoor is het per definitie niet mogelijk om ze veilig op te slaan in een TPM.

De blog post zegt ook

On Android your passkeys will be securely synced through Google Password Manager or any other password manager that supports passkeys.

Hoe ze Windows Hello gebruiken, is voor mij niet 100% helder. Volgens mij gebruiken ze de TPM alleen om de lokale key storage te unlocken en te authenticaten naar de AD - maar het bevat niet het key material zelf. Hierdoor is het bijvoorbeeld ook mogelijk om een PIN recovery te doen. Dit zie je bijvoorbeeld ook bij Bitlocker: er zit een kopie in de TPM voor lokaal gebruik, maar er is ook een externe non-TPM manier om bij het beveiligde materiaal te komen.

laurxp schreef:

[...] Het hele idee is dat het OS de sleutels opslaat in de cloud zodat ze op alle apparaten beschikbaar zijn - hierdoor is het per definitie niet mogelijk om ze veilig op te slaan in een TPM. [...]

Ik heb geen idee of en hoeveel verschillende TPM's (in PC's met Windows) er bestaan waarmee je daarin opgeslagen private keys kunt versleutelen voordat ze uit de TPM worden geëxporteerd, en je ze (in versleutelde toestand) naar TPM's kunt sturen en daarin ontsleutelen (nb. ik heb ook geen TPM specificaties bestudeerd).

Precies dat kan wel met Apple secure enclaves, en -vermoed ik- ook in dedicated hardware op (voldoende recente) Android devices.

Wellicht dat Microsoft zo terughoudend is over passkeys vanwege veel incompatibele TPM's in het veld?

Het hele idee van een HSM / TPM / Secure Enclave is juist dat de private key alleen bestaat in de HSM, en onmogelijk te exporteren is. Hierdoor weet je 100% zeker dat een cryptografische operatie is uitgevoerd door die ene specifieke HSM. Vaak worden de private keys daarom zelfs gegenereerd op de HSM zelf.

Ik betwijfel dat er HSMs zijn die de Passkeys kunnen hersleutelen, want dan moet je namelijk ondersteuning voor het parsen van de hele datastructuur implementeren, en waarschijnlijk zelfs het hele Webauthn protocol - terwijl je om veiligheidsredenen juist de HSM zo simpel mogelijk wil houden.

Zoals ik het begrijp, gebruikt men de HSM alleen zodat de lokale kopie veilig kan worden opgeslagen: sla de data op de PC op, ge-encrypt door de HSM. Laat de HSM de pincode vereisen voor het decrypten. Zonder de HSM en pincode is de opgeslagen data onbruikbaar, maar mét HSM+pincode kan je het gewoon decrypten en gebruiken, want het host-OS krijgt een unencrypted kopie van de Passkey terug.

Wellicht dat Apple met de Secure Enclave wél alles op de HSM doet, maar dat is de enige partij waar ik dat momenteel als mogelijkheid zie.

laurxp schreef:

Het hele idee van een HSM / TPM / Secure Enclave is juist dat de private key alleen bestaat in de HSM, en onmogelijk te exporteren is. Hierdoor weet je 100% zeker dat een cryptografische operatie is uitgevoerd door die ene specifieke HSM. Vaak worden de private keys daarom zelfs gegenereerd op de HSM zelf.

Dat weet ik, maar het probleem daarmee (vooral voor doorsnee consumenten) is dat als je die "HSM" kwijtraakt (bijv. notebook gestolen wordt of vervangen wordt) of het moederbord of de chip zelf defect raakt, je nergens meer kunt inloggen waar passkeys vereist zijn - tenzij je er een "schaduwsysteem" op na houdt én dat up-to-date houdt.

Als je, met foutgevoelig kunst en vliegwerk, twee of meer HSM's (of hardware keys) in de lucht moet houden om niet buitengesloten te raken, is de stap naar automatische (versleutelde) back-ups niet zo gek. En als je die niet kunt restoren op een nieuw device (na verlies van het oude), heb je daar weinig of niets aan.

Als je als consument bijvoorbeeld zowel een iPhone als een iPad hebt, is het wel zo handig als jouw passkeys tussen die apparaten worden gesynchroniseerd.

Als werkgever kun je jouw personeel smartcards (of Yubikeys etc.) met client-certificaat geven, of eventueel Yubikeys e.d. geven met pré-installed WebAuthn credentials. Met goed georganiseerd systeembeheer kun je, na kwijtraken van smartcards of hardware keys, accounts snel blokkeren en opnieuw provisionen.

Voor consumenten werkt dit model niet want big tech levert nauwelijks ondersteuning bij problemen.

Nb. de veiligheid van HSM's wordt m.i. overschat. Als het device dat met de HSM communiceert gecompromitteerd is, kunnen aanvallers handtekeningen zetten zonder zelf bij de private key(s) te kunnen (zie bijv. deze post).

Ik betwijfel dat er HSMs zijn die de Passkeys kunnen hersleutelen, want dan moet je namelijk ondersteuning voor het parsen van de hele datastructuur implementeren, en waarschijnlijk zelfs het hele Webauthn protocol - terwijl je om veiligheidsredenen juist de HSM zo simpel mogelijk wil houden.

FIDO2 hardware keys hoeven ook niet het hele WebAuthn protocol te ondersteunen, maar wel een deel daarvan.

De "passkey-deal" met de FIDO organisatie lijkt eruit te bestaan dat de functionaliteit van FIDO2 hardware keys wordt nagebouwd in "secure (hardware) enclaves" in smartphones, tablets en PC's, met één uitzondering: private keys kunnen (mits veilig versleuteld) tussen secure enclaves in separate devices worden uitgewisseld.

Zoals ik het begrijp, gebruikt men de HSM alleen zodat de lokale kopie veilig kan worden opgeslagen: sla de data op de PC op, ge-encrypt door de HSM. Laat de HSM de pincode vereisen voor het decrypten. Zonder de HSM en pincode is de opgeslagen data onbruikbaar, maar mét HSM+pincode kan je het gewoon decrypten en gebruiken, want het host-OS krijgt een unencrypted kopie van de Passkey terug.

Wellicht dat Apple met de Secure Enclave wél alles op de HSM doet, maar dat is de enige partij waar ik dat momenteel als mogelijkheid zie.

Ik heb geen idee hoe het precies werkt (per platform kan dit ook nog eens verschillen).

Puur speculatief: als elke Apple secure enclave dezelfde (niet exportable) "master" private key bevat, kun je data versleuteld tussen twee enclaves in willekeurige Apple devices uitwisselen (veilig totdat iemand toch die private key eruit weet te peuteren, maar laat ik dat even buiten beschouwing laten).

Als een gebruiker dezelfde toegangscode voor al diens apparaten gebruikt, en je die toegangscode onderdeel maakt van de feitelijk gebruikte sleutel (om o.a. private keys mee te versleutelen), kan versleutelde data uitsluitend tussen enclaves in apparaten van die gebruiker worden uitgewisseld.

In dat scenario heb je dus zowel de Apple "master" private key als de toegangscode van de gebruiker nodig om diens "secrets" (naast passkey-data ook keychain en in Safari opgeslagen wachtwoorden) te kunnen ontsleutelen.

Daarnaast is het denkbaar dat niet de hele "passkey database" onversleuteld in de secure enclave wordt bewaard, maar dat deze versleuteld in gewone opslag staat, met per record op z'n minst:

- plain text domeinnaam (om records te kunnen vinden);
- versleuteld: (domeinnaam, private key)

Op het moment dat de user met passkey op domein X wil inloggen, wordt het record voor domein X gezocht en gevonden, waarna het versleutelde deel uit het record voor X naar de secure enclave wordt gestuurd - om daar te worden ontsleuteld en verder verwerkt.

Nogmaals, dat was speculatie.

Affijn, zodra ik weer wat tijd over heb zal ik eens zoeken of hierover meer details te vinden zijn op internet.

Het hele idee van een HSM / TPM / Secure Enclave is juist dat de private key alleen bestaat in de HSM, en onmogelijk te exporteren is.

Dat is niet zo zwart-wit, keys kunnen en mogen best geëxporteerd worden. Het zou best lastig zijn anders om een redundante HSM setup te draaien als bijvoorbeeld een Certificate Authority. Dat dit wel mogelijk is: zie bijvoorbeeld AWS en Thales docs op het gebied van key export.

Ik betwijfel dat er HSMs zijn die de Passkeys kunnen hersleutelen, want dan moet je namelijk ondersteuning voor het parsen van de hele datastructuur implementeren, en waarschijnlijk zelfs het hele Webauthn protocol - terwijl je om veiligheidsredenen juist de HSM zo simpel mogelijk wil houden.

Nee, WebAuthn beschrijft de JS API die de browser implementeert en wat de server moet doen met de data die daarvan terugkomt. De browser doet het meeste werk hier, de client HSM heeft weinig mee te maken, behalve:
- een private key genereren en de bijbehorende public key kunnen teruggeven tijdens registratie
- signen van de server challenge tijdens registratie en authenticatie met de private key
De rest van een protocol is aan die client van dat protocol (WebAuthn/SSH/MIME/GPG/etc), HSMs zijn al simpel.

WebAuthn gebruikt bestaande standaarden voor public-key cryptography, en beschrijft dat de credentialPublicKey value met COSE moet worden geëncodeerd. COSE is eenvoudig om te zetten van/naar DER/PEM of PKCS8 door de browser en server voor signing/validation, en is nauw verwant met JOSE (zoals gebruikt door JWTs).

Mooie vooruitgang. Voorlopig houd ik echter liever bij een wachtwoordmanager met totp codes waar mogelijk. Werkt praktisch net zo, maar heb een stuk beter centraal beheer over alle gegevens.

Mooie vooruitgang. Voorlopig houd ik echter liever bij een wachtwoordmanager met totp codes waar mogelijk. Werkt praktisch net zo, maar heb een stuk beter centraal beheer over alle gegevens.

Wachtwoord managers als LastPass werken ook met FIDO.

Zelf gebruik ik daar YubiKey voor, heb op mijn bureau een USB stand staan, met daar in een YubiKey 5, wordt er een paswoord gevraagd, even aanraken, en dan wordt er direct een unieke eenmalige key gegenereerd en verzonden, en kan je weer veder.

Werkt bijzonder snel en met een niveau hogere veiligheid.

Cryptographic Specifications RSA 2048, RSA 4096 (PGP), ECC p256, ECC p384

Veel geluk om ECC p384 te kraken, om bij mijn data te komen.

[Reactie gewijzigd door player-x op 9 december 2022 15:23]

ECC p256 en p384 zijn al deprecated door de NSA, dus de maker heeft er al niet héél veel vertrouwen in. Daarnaast is er sinds Dual_EC_DRBG de nodige twijfel over NSA-gemaakte encryptiestandaarden, en is er in theorie ruimte voor een backdoor in deze curves. De gebruikte constants zijn op zijn minst verdacht te noemen.

Persoonlijk blijf ik liever bij Curve25519 - dat is vanaf het begin ontworpen om transparant, veilig, en foolproof te zijn.

Voor mij heeft encryptie het doel om criminelen en hackers buiten te houden, en YubiKey 5 ondersteund alleen RSA en ECC als sleutels.

ECC wordt gezien als de betere sleutel, en zelfs als de NSA de sleutel kan hacken, wat helemaal niet zeker is, is het is vrij zeker niet niet te doen zonder veel tijd op een big iron.
En voor hun valt er sowieso weinig te halen bij mij (mijn p0rn collectie misschien? ;-), voor cybercriminelen daar in tegen wel, dus kies ik voor de betere sleutel.

De juiste keuze, ik weet het niet helemaal zeker, maar denk het wel.

Curve25519 is een ECC sleutel, en de Yubikey 5 heeft daar sinds firmware 5.2.3 uit 2019 ook ondersteuning voor!

Overigens ben ik wel benieuwd hoe je het gebruikt om je data te encrypten, want het is asymmetrische cryptografie. Welke tool gebruik je daar voor, als ik dat mag vragen?

[Reactie gewijzigd door laurxp op 9 december 2022 16:33]

Zie dus ook: nieuws: 1Password krijgt begin 2023 passkeys voor wachtwoordloze authenticatie

Het probleem op smartphones is dat de vingerafdrukscanner of de gezichtsherkenning niet 100% is, daardoor vallen ze na een paar mislukte pogingen terug naar een pincode en als iemand die pincode weet dan is het klaar. Zo weet ik de pincode van mijn vriendin en zij de mijne. Onschuldig voorbeeld, maar heb ook een vechtscheiding gezien waar zij vanaf zijn telefoon alle accounts blokkeerde. Whatsapp, Facebook, Outlook, zelfs Ring werd geblokkeerd.

FIDO creëert een schijn van veiligheid. Een goed wachtwoord i.c.m. 2FA is nog steeds de beste methode.

Als je er over nadenkt is je smartphone de single point of failure in je hele leven. Als dat ding eraan gaat dan is daarmee meteen ook alles weg.

[Reactie gewijzigd door TechSupreme op 9 december 2022 14:57]

Jup, vingerafdrukken en gezichtsherkenning zijn vrij onbetrouwbaar.

Voor een flink deel van de populatie werken vingerafdrukscanners zéér matig, en bij gezichtsherkenning is het niet heel anders. Aan de andere kant zijn ze ook relatief eenvoudig te faken, dus veel veiligheid bied het ook niet. En als iemand eenmaal een kopie van een gezichts/vingerafdrukscan heeft, kan je moeilijk een nieuwe vinger of gezicht groeien.

Dan moet je de pincode niet met je vriendin delen . Geen enkele authenticatie-methode beschermt tegen het vrijwillig weggeven van je wachtwoord/pin-code

FIDO creëert een schijn van veiligheid. Een goed wachtwoord i.c.m. 2FA is nog steeds de beste methode.

Hoezo? Als ik m'n 'goede wachtwoord' aan m'n vriendin vertel dan kan zij nog steeds vanalles uitspoken.

En hoe ga je een sterk wachtwoord onthouden voor alle tientallen accounts die een persoon vaak heeft? Password manager is altijd slim, maar dan moet je dus wederom niet je master-wachtwoord tegen anderen gaan vertellen.

Als je er over nadenkt is je smartphone de single point of failure in je hele leven. Als dat ding eraan gaat dan is daarmee meteen ook alles weg.

Nieuwe telefoon kopen, backup terugzetten, en doorgaan. Kost je nog geen uur

Dan moet je de pincode niet met je vriendin delen .

Het was maar een voorbeeld. Punt is dat een pincode alleen al zwak is, iemand kan hem afkijken, of jou dwingen om hem af te staan. Misschien dat je hem in vertrouwen deelt met iemand die er dan misbruik van gaat maken.

Nieuwe telefoon kopen, backup terugzetten, en doorgaan. Kost je nog geen uur

Nieuwe simkaart nieuw nummer? En de accounts die je kwijt bent? Die komen niet met die backup terug.

[Reactie gewijzigd door TechSupreme op 9 december 2022 15:45]

Nieuwe simkaart nieuw nummer? En de accounts die je kwijt bent? Die komen niet met die backup terug.

Meerdere authenticators registreren (wat bij FIDO een inherent onderdeel is van de standaard) en een hardware key in de kluis leggen. Of een sheet met one-time recovery codes uitprinten als de dienst waar je op inlogt zo iets ondersteunt.

Passwordless login met passkeys is om het makkelijk en veilig te (proberen te) maken voor dagelijks gebruik. Je kunt gerust minder makkelijke authenticatie koppelen voor niet alledaags recovery gebruik.

Dat is het hele klote gedoe met TOTP, moet je die 30 accounts weer allemaal opnieuw gaan toevoegen.
Zelfde met alle bank apps, moet je ook opnieuw registreren. Een nieuwe telefoon is gelijk een minstens 8 uur werk ...

Dat is het hele klote gedoe met TOTP, moet je die 30 accounts weer allemaal opnieuw gaan toevoegen.
Zelfde met alle bank apps, moet je ook opnieuw registreren. Een nieuwe telefoon is gelijk een minstens 8 uur werk ...

En daarom kun je dus passkeys automatisch synchroniseren.
Dat is een compromis tussen het risico op uitlekken en het gebruiksgemak.

[Reactie gewijzigd door R4gnax op 9 december 2022 21:26]

Een goed wachtwoord kan ook afgekeken worden. Als er een keylogger op je systeem staat ben je al helemaal klaar. Met FIDO heb je dat probleem niet, lijkt me wel degelijk veiliger.

PIN-code op telefoon kan je ook langer maken, of je kan er een wachtwoord van maken. Ook heb je bij een telefoon een extra laag van de beveiliging: Je moet de telefoon fysiek in handen hebben, en misbruiken voordat de rechtmatige eigenaar deze op afstand blokkeert. Als je zowel je telefoon als je pincode uit handen geeft, dan houdt het helaas wel echt op. Zelfde geldt voor je pinpas en pincode.

Nieuwe simkaart nieuw nummer? En de accounts die je kwijt bent? Die komen niet met die backup terug.

Waarom zouden mijn accounts kwijt zijn? In die backup (of in de cloud) staat de data van m'n password-manager....... met die wachtwoorden kan je weer je account in.
Mocht je inderdaad 2fa via SMS hebben, en afhankelijk zijn van je telefoonnummer, dan kan je vaak simpelweg een nieuwe sim-kaart aanvragen voor hetzelfde nummer.

Elke methode heeft zijn eigen voor en nadelen, en mogelijkheden om deze op te lossen

Even goed lezen, ik zei een goed wachtwoord IN COMBINATIE MET 2FA.

Heb je ooit geprobeerd om een Facebook account te herstellen? Of Whatsapp? Dat heb je echt niet zomaar 1, 2, 3 gedaan.

[Reactie gewijzigd door TechSupreme op 10 december 2022 00:20]

Even goed lezen, ik zei een goed wachtwoord IN COMBINATIE MET 2FA.

Dus? Je doet nu alsof 2FA totaal niet te backuppen is
Authy, één van de bekendere 2FA apps slaat je 2FA gegevens versleuteld op.

Backup
Prevent account lockout when you lose your phone.

Ook staat er bij het instellen van 2FA er vaak bij dat je de gegevens óók ergens anders moet opslaan, voor het geval dat je je telefoon oid verliest. Kijk maar.

Heb je ooit geprobeerd om een Facebook account te herstellen? Of Whatsapp? Dat heb je echt niet zomaar 1, 2, 3 gedaan.

Ja, fluitje van een cent, nog nooit een enkel probleem gehad.... als je tenminste de instructies leest, (aka. "Even goed lezen")

Denk je dat ik nog nooit een nieuwe telefoon gekocht heb in m'n leven? Of dat ik alle 100 accounts opnieuw moet instellen wanneer ik dat doe? De realiteit is: Ik heb een nieuwe telefoon -> zet backup via iCloud terug -> ik heb toegang tot al m'n accounts. oude telefoon is hier nergens nodig geweest

Je verzint allemaal scenario's die duidelijk niet de bedoeling zijn (pin-code delen / geen backups maken) en negeert dingen als keyloggers bij normale wachtwoorden.

Iedereen heeft zijn eigen voorkeuren, niks mis mee, maar FIDO een "schijn van veiligheid" noemen is gewoon kul

backup?

Vingerafdrukken als factor - of andere biometrie, ik blijf het maar herhalen - doe dat niet. Het is meetbaar dus is het namaakbaar.
We weten dat Apple, Microsoft, Google en velen dat promoten, maar het is niet onfeilbaar - en als iemand binnen wil zijn dan scannen ze uw gezicht - of ze dwingen u uw vingerafdruk te zetten, of erger. De verhalen zijn bekend waarbij een agent gewoon de telefoon voor het gezicht houdt en laat aanmelden... Dus dat is zo goed als GEEN beveiliging en zal enkel helpen bij verlies van het toestel.
Veel beter is de combo van een pincode en een hardware-sleutel (of dat al dan niet met nfc is - laat ik in het midden).
SMS gebruiken in een MFA-omgeving zou ik ook niet doen - dat kan vervalst en/of onderschept worden.
Een dongle is geen dongle - dus je moet er meerdere hebben.
En laten we eerlijk blijven - zou u uw smartphone met de cloud durven koppelen aan al uw bankrekeningen incl. pensioenfondsen, beleggingen... Gezien er overal zoveel lekken in zitten - ben ik voorstander om toch maar zoveel mogelijk schotten en barrieres te plaatsen en de toegang tot wat waardevol is zeer streng af te lijnen hoe ik dat gebruik.
E-ID voor medische data (niet op smartphone!) - en bankieren - met de kaartlezer NIET aan het toestel gekoppeld (manueel overtikken dus) - dus ja geen QR-codes (die horror gaat pas beginnen met valse QR's) - en geen onmiddelijke betalingen (ik ben tegen omdat als het mis gaat - je geen schijn van kans meer hebt om snel de stop knop te laten gebruiken en die overschrijvingen alsnog te torpederen).
U doet natuurlijk wat u wil - maar zelf kies ik voor de ultrastrenge, strakke benadering van security. Trop is teveel en keep things simple!

Voordat iedereen gaat vallen over het wel of niet betrouwbaar zijn van een bepaalde inlog methode: Met MFA, MultiFactorAuthenticatie is het de bedoeling om meerdere methodes te gebruiken zodat het bij elkaar opgeteld beter beveiligd is.

Dan is elke toevoeging welkom. Dat er dan bij die mfa 5 of 10 of 20 methodes zijn ingesteld en er per keer 2 of 5 gebruikt worden is onderdeel van die beveiliging.

Dus ook deze methode is welkom. Ze draagt aan de ene kant bij aan extra mogelijkheden voor mfa-controle. Aan de andere kant biedt ze de mogelijkheid van eenvoudiger inloggen.

Bedenk dat je bij de eerste keer inloggen op zo'n site meer mfa-toegang testen moet doorlopen. Onder water zal er het nodige worden vastgelegd in koekjes en dergelijke en over en weer. Daarna kan je sneller/makkelijker inloggen tot je die koekjes weggooit, dan moet je weer door de hele mfa-toegang heen. Je zal er op een ander systeem in ieder geval alleen met de grootste moeite gebruik van kunnen maken, er zal onder water ook vast wel een 'fingerprint' van jou systeem gemaakt worden. Dat wordt ook allemaal onderdeel van de mfa-beveiliging.

Ja, alleen een pincode is niet genoeg. Ja, een sms als token is niet zo veilig. Maar als onderdeel van mfa zijn het extra factoren in de authenticatie en verhogen ze wel de beveiliging.

Ik heb nu al een paar maanden een 2 FIDO keys, maar het zijn super nutteloze dingen in mijn opzicht omdat ik het nergens kan gebruiken om in te loggen.

Goede zaak, maar helaas nog geen linux ondersteuning begrijp ik?