Zoals ik het begrijp, zit de passkey in je CPU opgeslagen. In het non-volatile geheugen van de TPM (Trusted Platform Module, trusted for whom?).

Als je CPU stuk gaat, en deze de TPM meesleurt in zijn dood, dan kan je nooit meer bij je verloren passkeys.

Hier is wel een oplossing voor gevonden. Je kan via de cloud je passkeys kopiëren naar nieuwe devices in de buurt. Vraag mij niet hoe dat werkt en of dat de voordelen van de passkey niet teniet doet.

Een TPM is in staat een sleutel binnen zichzelf aan te maken. Daar heeft het de mogelijkheden voor. Maar je kan ook op je computer een sleutel maken en die later in de TPM opslaan. Ik denk dat dit is wat er in de praktijk gebeurt zodat je backups kan maken in de cloud (waar het ook handig beschikbaar is voor opsporingsdiensten over de hele wereld).

TPN
Dat klopt niet. de TPM chip is een aparte chip op je moederbord.

Dat is niet in alle gevallen zo; moderne CPU's (Intel vanaf de 8e of 9e generatie) heeft ook een vTPM, dan ben je niet meer afhankelijk van een aparte module op je moederboard. Ook een van de redenen waarom Windows 11 modernere CPU's vereist.

Zover ik weet kan de TPM als module in je moederbord geprikt worden. Daarna zat de TPM in de chipset van je moederbord en tegenwoordig zit die vaak in de CPU zelf. Zodat je er niet omheen kan als computer gebruiker.

Hij heet ook wel de 'Fritz chip' naar de Amerikaanse senator die hem heeft bedacht. Hij is oorspronkelijk bedoeld als digital rights management. Tegen illegaal kopiëren dus.

Anoniem 17:08

Dat zal kloppen. Maar de TPM chip is niet verbonden met mijn fysieke Passkey,
in mijn geval een USB device met biometrie.
Die laatste factor maakt 'm meer divers dan de meeste passkeys die die factor missen.

Gewoon om de te verwachten generieke statements alvast te de-railen.

Het is KeePass en nee, ik heb geen zin meer.

#1337 (om 13:38)

Wil je nu weten hoe een Passkey werkt (paswordless login), aangezien je ook schrijft:


Of bedoel je Passkey in plaats van Keypass, aangezien je verderop ook schrijft:


Verwarrend al die verschillende terminologie. Als jij al niet precies weet wat je wil eten, hoe moeten wij daar dan op antwoorden?

Aangezien Erik geen zin meer heeft:
https://www.pivotpointsecurity.com/podcasts/episode-149-unlocking-the-future-passkeys-and-passwordless-authentication/

Ja advies dus Passkeys gebruiken
ENZ ENZ
Zoveel mogelijk
Als het mogelijk is
In combi met 1PassWords

OAuth 2.0 hoeft niet passwordless te zijn. Mijn ouders hebben een gmail account op Thunderbird voor Windows 10 en de computer is superoud. Uit 2011. Deze heeft geen TPM mogelijkheid en toch werkt gmail met Thunderbird daarop.

Als je moet verifiëren in Thunderbird dan krijg je een browservenster met recaptcha's. Daarna zeurt gmail er voor maanden niet meer over. OAuth 2.0 gebruikt cookies en javascript.

https://support.mozilla.org/nl/kb/automatische-omzetting-van-google-e-mailaccounts-n#thunderbird:win10:tb140-esr

Voor Windows Hello is een TPM vereist als je gezicht, vingerafdruk en waarschijnlijk ook pin wilt gebruiken.

Anoniem 17:08

Hou je wachtwoorden gewoon in eigen beheer, dus zonder derde partijen. Memorize ze en bewaar ze daarnaast ergens veilig offline.

iedereen vindt weer wat anders. Zo lastig is het. Ik denk dat het vaak iets zegt over de gebruiker zelf. Hoe angstig ben je , hoe achterdochtig.Onzeker of hoeveel vertrouwen heb je. Het beste is natuurlijk wanneer je dat gevoel hebt op basis van feiten.
Zoals:
Hoe vaak is Bitwarden (of een andere) gehackt? Hoeveel slachtoffers zijn er door het gebruik van wachtwoordmanagers per maand.. Hoe vaak zijjjn KeePass gebruikers de sigaar. (database op usb maar trok de usb eruit zonder te deactiveren, gegevens weg)Hoe vaak verliezen mensen hun papieren lijstje (per ongelijk weggegooid door de werkster, nieuwe wachtwoord fout opgeschreven , was het wachtwoord nu een (hoofdletter Ll1liI of een 0Oo kleine letter per abuirs als grote letter geschreven)
Kortom. gevoelens en feiten........door elkaar geuit op de medium hier.
CONCLUSIE:

Het blijft dus steeds je eigen oordeel zien te vormen in een chaos aan meningen (want dat zijn het vooral denk ik)

Ik dacht dat sinds 2013 alle moederboarden die gemaakt zijn, allemaal in-chip backdoors hebben voor de NSA. Helaas. Dit nieuws las ik rond die tijd, maar dat nieuws verdween heel snel. Iets om rekening mee te houden, dat die mogelijkheid al jaren aanwezig is.

Je haalt allemaal zaken door elkaar die niet direct met elkaar te maken hebben zoals SSO en passkeys... Single Sign-On heeft niets met de inlogmethode te maken...

Er zijn ook heel veel sites die het allemaal prima uitleggen maar kort door de bocht: Passkeys zijn veel veiliger dan de huidge inlognaam/wachtwoord+MFA. Is het perfect? Nee. Wil je perfectie -> Yubikeys

Yubikeys zijn hardwarematige (FIDO) sleutels... Die kun je dus niet opslaan in een wachtwoord manager en daardoor veiliger.

Simpele uitleg over passkeys:
https://www.dashlane.com/blog/what-is-a-passkey-and-how-does-it-work

Uitgebreide uitleg:
How Passkeys Work - Computerphile
https://www.youtube.com/watch?v=xYfiOnufBSk

Simpele (NL) uitleg van passkeys

Voor de opslag van passkeys (aan jouw kant) heb je een soort wachtwoordmanager nodig (de meeste moderne wachtwoordmanagers ondersteunen passkeys). Als je niets ziet van een aparte wachtwoordmanager, komt dat doordat de noodzakelijke functionaliteit in jouw browser zit. De server moet natuurlijk ook passkeys ondersteunen.

1) Op passkey demo websites, zoals https://webauthn.io, kun je gratis als test een passkey aanmaken. Vul een willekeurige naam in (jouw account wordt na 24 uur gewist door die site). Ik heb zojuist "PietjePuk" gebruikt; kies iets anders.

2) Druk op "Register". Jouw browser genereert dan een nieuwe passkey. Die bestaat uit twee gigantisch grote willekeurige getallen die ik G1 en G2 noem (rekenkundig aan elkaar gerelateerd, maar niet te raden).

3) Vervolgens wordt G1 als een soort wachtwoord naar de website gestuurd. De webserver maakt dan een account (record in hun database) met daarin:
• als naam: "PietjePuk";
• als "wachtwoord": G1.

4) Ook in jouw wachtwoordmanager wordt een record aangemaakt:
• de domeinnaam van de website met jouw account: "webauthn.io";
• als naam: "PietjePuk";
• als "wachtwoord": G2.

Nb. ook als je het account aanmaakt op een subdomein (zoals "passkey.test.webauthn.io") wordt in het record de "eTLD+1" domeinnaam opgeslagen, nl. "webauthn.io".

5) Als je https://webauthn.io gesloten had, open deze dan opnieuw.

6) Je hoeft géén gebruikersnaam in te vullen! Als deze er nog staat mag je die tekst weghalen, laten staan mag ook.

7) Druk op "Authenticate" om in te loggen. Nb. het WebAuthn protocol vereist dat de server een geldig certificaat heeft en dat er van https gebruik gemaakt wordt.

8) Jouw browser vraagt nu aan jouw wachtwoordmanager om te zoeken naar alle passkey records met als domeinnaam "webauthn.io". Dat gebeurt ook als je een subdomein zou hebben geopend, zoals de fictieve domeinnaan "passkey.test.webauthn.io".

9) Als er niks in het naamveld op de voorpagina van https://webauthn.io was ingevuld en je méér dan één account op die website hebt, vraagt jouw wachtwoordmanager (of browser) op wélke van die accounts je wilt inloggen (als je slechts één account hebt, wordt deze vraag overgeslagen).

10) Als het goed is moet je nu met biometrie (vingerafdruk, gezichtsscan of eventueel ontgrendelcode) aantonen dat jij jij bent (in iOS en iPadOS zit nog steeds een kwetsbaarheid waardoor, onder specifieke onetandigheden, bijv. een dief of ienand aan wie je jouw iDevice uitleent, deze stap kan omzeilen).

11) De wachtwoordmanager stuurt nu de door jou gewenste gebruikersnaam naar de website.

12) De website zoekt jouw account-record erbij (zie stap 3). Als dat account niet (meer) bestaat op de server stuurt die server een foutmelding naar jouw browser. Als jouw account wel bestaat meldt de server dat stilletjes aan de browser.

13) De browser haalt de volledige domeinnaam uit de adresbalk; in theorie zou dit "passkey.test.webauthn.io" kunnen zijn. Tezamen met nog andere gegevens vult de browser een tijdelijk record en ondertekent dat digitaal met G2 (hoe digitaal ondertekenen werkt is te ingewikkeld om hier uit te leggen, zie https://security.nl/posting/884482). Dat record stuurt de browser naar de server.

14) De server gebruikt G1 om de digitale handtekening te verifiëren. Als die klopt weet de server dat jij dezelfde PietjePuk moet zijn als degene die het account aanmaakte.

15) De server moet nog een check doen, nl. of jij (met jouw passkey) überhaupt wel op de werkelijke (sub-) domeinnaam mag inloggen. Met een passkey voor google.com mag je namelijk beslist niet op een https://sites.google.com pagina kunnen inloggen, want die pagina's zijn van (potentieel kwaadaardige) klanten van Google. In https://github.com/w3ctag/design-reviews/issues/97#issuecomment-175766580 schrijft een Google-medewerker op welke subdomeinnamen je wél mag inloggen (dat is al even geleden, het lijstje kan veranderd zijn).

16) Als alles OK is logt de server jou in, door een (1FA) session-cookie naar jouw browser te sturen.

a) Het belangrijkste voordeel is phishing resistance: je kunt met een passkey niet inloggen op een nepwebsite met een afwijkende domeinnaam, simpelweg omdat de wachtwoordmamager bij stap 8 geen record kan vinden (als je een passkey voor lidl.be zou hebben, en je probeert in te loggen op lîdl.be/login, dan lukt dat niet - wat je ook probeert).

b) De getallen G1 en G2 (uniek voor elke passkey) zijn te vergelijken met ongebruikelijk lange random, niet te raden, wachtwoorden.

c) De rest van de vaak geclaimde voordelen van passkeys, zoals "asymmetrische encryptie", zijn marketing bla bla. Het session-cookie dat je ontvangt vormt nog steeds een enorm zwakke schakel in de keten. Daarnaast kun je bijna altijd op alternatieve wijze inloggen (zonder passkey, bijv. als je die onverhoopt kwijtraakt), en kun je dus op een nepsite worden overgehaald om dat te doen. Dat een inbreker op de server er niets aan heeft als hij G1 in handen krijgt, klopt. Maar dat geldt ook als je voor elk account zelf een uniek wachtwoord gebruikt. Indien een inbreker toegang krijgt tot een account database op een server, kan hij zijn passkey (zijn G1) toevoegen aan jouw account, of jouw G1 door de zijne vervangen.

d) Het is ondoorzichtige technologie (net als TOTP MFA/2FA) waardoor het risico op het kwijtraken van (toegang tot) de database van de wachtwoordmanager groot is, met multiple account lockouts als gevolg. Dit is vooral een risico als je de in Android en iOS/iPadOS ingebouwde wachtwoord+passkeymanagers gebruikt, waar je zelf nauwelijks of niet backups van kunt maken.

e) Google's passkey manager is cloud based. Het is doodsimpel om per ongeluk die database te wissen (notabene als je instructies van Google volgt). Google claimt zelf niet bij jouw passkeys te kunnen, maar dat is een leugen. Zie https://seclists.org/fulldisclosure/2024/Feb/15.

f) Ik schreef het eerder: onder bepaalde omstandigheden vragen iOS en iPadOS niet om lokale authenticatie om passkeys (en wachtwoorden) uit (wat eerder de iCloud Keychain werd genoemd) te ontsluiten; zie https://todon.nl/@ErikvanStraten/115658045799601168.

g) Als je op een website achter een TLS-MitM proxyserver (zoals van Cloudflare en Fastly) inlogt, kunnen beheerders van zo'n proxyserver jouw (ook met passkeys of Yubikeys beveiligde) accounts kapen. De domeinnaam verwijst dan naar de proxyserver waar jouw browser een https ("E2EE") verbinding mee heeft - dus géén E2EE met de gesuggereerde server.

h) Indien een nepsite, na het ongeautoriseerd wijzigen van een DNS-record of middels een BGP-hijack, (in no time) een geldig https servercertificaat verkrijgt, is een AitM aanval mogelijk waar passkeys en FIDO2 hardware keys jou niet tegen beschermen.

i) Als bijv. jouw telefoon (of FIDO2 hardware key) gestolen wordt en de dief erin slaagt om jouw biometrie te faken (zie ook f) bestaat er geen mechanisme om in één keer al jouw passkeys in te trekken (ook voor wachtwoorden bestaat dit niet, maar zoiets had natuurlijk in WebAuthn kunnen worden geïmplementeerd).

j) Last but not least: passkeys beschermen je niet bij het toevoegen of vernieuwen van een passkey voor een bestaand account. Als je een phishingbericht krijgt waarin staat dat je een (nieuwe) passkey moet aanmaken op bijvoorbeeld
(de laatste punt heb ik door • vervangen), moet je ongetwijfeld inloggen op de oude manier. In de gegenereerde passkey zijn de criminelen niet geïnteresseerd, zij hebben nu op de oude manier toegang tot jouw account verkregen.

In 2023 schreef ik https://www.security.nl/posting/798699/Passkeys+voor+leken.
Shortlink naar deze reactie: https://security.nl/posting/929755.

SVP niet deze hele reactie quoten!

In aanvulling op mijn laatste reactie hierboven, getiteld Simpele (NL) uitleg van passkeys (zie https://security.nl/posting/929755) heb ik op Mastodon een draadje geschreven met een heel stel screenshots.

Daarin is te zien hoe je passkeys kunt aanmaken en ermee inloggen m.b.v. de KeePassDX wachtwoordmanager onder Android, zie https://todon.nl/@ErikvanStraten/116286748831538127 en verder.

nee, dat zie je heel erg verkeerd.

"gewoon lang random password gebruiken" - heeft als risico dat de geheimhouding tijdens invoeren volledig berust bij de TLS sessie waarin het hopelijk ingepakt zit .
En een slecht ontworpen - of volledig gekraakte site - waar je dat password invoert ziet dus dat password, en slaat het (of de hash ervan) op.

En die mitigatie van dat risico moet volledig komen uit jouw opsec gewoonte om dat password echt nergens anders te gebruiken (en zo af en toe te wisselen ).


Een public-key stijl credential : dan ziet zowel een MITM onderweg nooit de werkelijke key, en een compromised site ziet OOK niet de credential .

Voor de ietwat technische mensen : passkey is vergelijkbaar met ssh public-key gebaseerd inloggen . (~/.ssh/authorized_keys) . En dat is een _enorm verschil_ met password gebruiken.
Een aanvaller die het hele sshd proces kan monitoren kan _wel_ het password zien langskomen (na decryptie , als invoer aan de password hash) , en kan _niet_ de ssh secret key van een inlogger zien .

Dat is geen bla bla, maar gewoon een reeel voordeel vergeleken met het sturen van het werkelijke password en hopen dat het eindpunt niet compromised is en de sessie encryptie een paar lagen eronder ook niet compromised is.

(knip berg risico's die niet passkey-specifiek zijn)

"passkey : hetzelfde als ssh-public-key inloggen maar dan voor webdingen" is m.i. de simpelste uitleg voor mensen die (al) bekend zijn met ssh .
En dat is heel fundementaal anders dan "inloggen met random password" .

Insgelijks.

Ook als je met een passkey inlogt stuurt de server een 1FA plain text cookie (of een ander token) via diezelfde verbinding. Als een aanvaller (en/of Cloudflare) dat in handen krijgt is het ook game over voor je.

Ik ben er overigens aan gewend dat als ik met dit argument kom, dat onvoorwaardelijke passkey fanaten schrijven dat cookies buiten de design spec van passkeys vallen. Droom lekker verder met je scope, ik wil veilig inloggen en internetten. Aan sterke schakels aan een ketting met ook zwakke heb ik niets.

Dan is mijn (per account unieke) wachtwoord mijn kleinste zorg, sterker: nul. Mijn grootste zorg is dat kwaadwillenden dan bij mijn vertrouwelijke data op die server kunnen en/of mij kunnen impersoneren.

Daar zorgen mijn wachtwoordmanagers voor.

Met welk doel precies? Omdat Microsoft het zei? Onder welke steen heb jij geleefd?

Dat boeit niet. De MitM neemt de sessie over zodra het 1FA cookie voorbij komt, en de aanvaller met ongeautoriseerde toegang tot de server voegt zijn passkey's public key toe aan mijn account, of vervangt mijn public key met de zijne.

Waarom lees je niet eerst wat ik al schreef voordat je roeptoetert?

SSH is voor zover ik weet, geen "connectionless" protocol zoals http met een TLS sausje (samen bekend als https). Die protocollen zijn daarom, juist op dit punt (connectionless en session cookies) slecht met elkaar te vergelijken.

Anderzijds moet je maar zien hoe je bij SSH jouw public key veilig op de server krijgt (en niet op een MitM "Trust on first Use" server. Ik heb zat beheerders SSH naar een server zien gebruiken waar zij nog geen account op hadden, maar hen nooit zien checken of het om de juiste server ging - wat meestal, lees op afstand, knap lastig is als je dat pas doet als die server ergens anders staat). {Edit 00:59: zie discussie in https://news.ycombinator.com/item?id=43694439.}

Een slechte vergelijking dus.

Ja, maar dat heeft 0,0 met passkeys te maken !
Als je met een random password en MFA inlogt, of met een X509 certificaat - zul je typisch OOK een sessie cookie krijgen.

Waarom haal je er irrelevante zaken bij ?!

"Als je met een passkey inlogt kan iemand die achter je staat alles zien wat je op de website aan het doen bent !"


Tsja, als je een bord voor je kop blijft houden zul je telkens ontdekken dat je tegen muren botst.

authenticatie methoden gaan over authenticatie . De _rest_ moet dan liefst ook nog veilig zijn, maar het is natuurlijk onzuiver redeneren om (en zeker precies één) authenticatie methode iets te verwijten die inderdaad buiten scope valt.


Fijn voor jou dat jij dankzij grote zorg aan jouw kant een bepaald probleem niet hebt.
Een authenticatie methode die ervoor zorgt dat het hele probleem _voor niemand_ bestaat is gewoon beter.
Hoeven normale mensen geen extra moeite voor te doen, krijgen ze hetzelfde resultaat zonder grote speciale oplettendheid en moeite .


Mooi voor jou. Nog mooier als dat resultaat "vanzelf" bereikt wordt en min of meer "niet fout gedaan KAN worden" . Veel beter dan "gaat alleen maar goed voor superprecieze experts die altijd goed opletten" .



Je doet toch alsof in je in de security werkt ? Waarom weet je dat dan niet ?

De reden om met een (langere periode dan vroeger) "vaste" credentials zoals passwords te wisselen is nog steeds omdat je niet kunt weten of ze niet eens gelekt zijn - omdat je ze telkens weer aanbiedt .
Die wisselperiode is een heel natte vinger en "tegenwoordig" langer dan vroeger.


Heb ik gedaan. Geen waardering voor. Je mist gewoon conceptueel overzicht.

Iemand die passkeys gelijk stelt aan passwords en asymmetrische encryptie afdoet als (irrelevante) marketing bla bla snapt gewoon het hele concept niet.

Jouw je ongelijk laten zien is waarschijnlijk hopeloos, maar overige lezers zijn hopelijk wel geholpen met een uitleg dat passkeys gewoon een ander - en beter - concept zijn dan passwords , omdat een aantal password-specifieke problemen gewoon niet bestaan in een passkey-systeem.



Voor het authenticatie deel is de analogie perfect .

Dan laat je je weer afleiden door andere delen (sessie en stateless-met-state) die minder overeenkomen.
Overigens heeft ssh in de sessie ook cookies om sessies uit elkaar te houden (het is niet puur van tcp sessie state afhankelijk) .


En weer haal je er een irrelevant zijpad bij - of je nu je account met password+mfa bij de "verkeerde" site aanmaakt, of inlogt bij op "de verkeerde" ssh server is ongeveer hetzelfde probleem .


In de praktijk kan het gewoon zijn "collega admin zet de ssh key van nieuwe collega op de server" . Daarmee is er nooit een password access _nodig_ (of mogelijk) en dus geen password exposure als er een mitm tussen zit.
Andere trust-bootstrap modellen voor SSH is werken met certificate based hostkeys , waarbij een (wsl enterprise-interne) CA de trust garandeert .
Ik zou me ook kunnen voorstellen dat bij server deploy de host key ervan assigned wordt (of in elk geval : de resulterende known_hosts files "out of band" gedeeld worden.

Maar de "trust bootstrap" van het zorgen dat je een eerste keer "met de echte" bestemming contact hebt is een ander probleem dan authenticatie .
Een deel van de mechanismen kan natuurlijk hetzelfde zijn.

Heel simpel : passkeys _zijn_ de web-login analogie van 'ssh pubkey authenticatie' . Uitstekende analogie.

Tip voor iedereen : systemen worden in lagen en modulair gebouwd juist om ze overzichtelijk te maken, met bekende eigenschappen en garanties (en beperkingen) in een laag of in een module , zodat je het systeem kunt analyseren.

Daarvoor is in netwerk land het ISO/OSI model in 5/7 lagen verdeeld met verschillende functies , daarom wordt software in modules en objecten ontwikkeld , daarom is unix groot geworden met tooltjes met een specifieke functie die achter elkaar ge-piped kunnen worden.

Door (bewust? ) in je bespreking van één component allerlei beperkingen of risico's te noemen van andere componenten maak je het alleen maar ondoorzichtig .
Als je ooit iets moet ontwerpen (of evalueren) is dat een slechte eigenschap

Na de "argumenten" van anoniem @02:15 hierboven het volgende.

1) De essentie is voorkómen dat een ongeautoriseerd persoon (of bot) toegang krijgt tot uw account.

2) Passkeys en FIDO2 hardware keys (zoals Yubikey en Google Titan), shared secrets (zoals wachtwoorden en TOTP codes) en 2FA/MFA via SMS zijn elk geen doel maar een middel om wat ik bij punt 1 schreef te voorkómen.

3) Elk bij punt 2 genoemd middel heeft vóór en nadelen; geen enkel middel is perfect. Bovendien zijn er vaak verschillen in implementaties (per fabrikant of software-leverancier).

4) WebAuthn (het protocol gebruikt door zowel passkeys als FIDO2 hardware keys, die laatste mits in WebAuthn modus) is, ruwweg, "beter" dan sterke (en unieke wachtwoorden), om verschillende redenen, waaronder:

• Phishing-resistentie: bij WebAuthn checken de browser en de wachtwoordmanager (samen met de server) of de domeinnaam klopt. Als die niet klopt kunt u niet inloggen (met WebAuthn). Enigszins vergelijkbare functionaliteit is standaard beschikbaar in Android, iOS en iPadOS (Autofill): ook voor wachtwoordmanagers van derde partijen (zie https://security.nl/posting/840236). In de screenshots onder https://todon.nl/@ErikvanStraten/116286748831538127 kunt u zien hoe Autofill werkt onder Android (op iDevices is dat vergelijkbaar) - zowel voor passkeys als voor wachtwoorden.

• WebAuthn vereist https. Anderzijds kunt u de meeste browsers zo instellen dat die browser u uitgebreid waarschuwt als er van http (ipv https) gebruik gemaakt wordt (zie https://security.nl/posting/876137 en ook bovenaan die pagina - getiteld "Veilig Inloggen").

• De voor WebAuthn gegenereerde publieke sleutel (die ik eerder G1 noemde) is enorm veel sterker dan wat websites toestaan voor wachtwoorden (veel websites stellen krankzinnige eisen aan wachtwoorden, in elk geval qua maximale lengte).

5) Passkeys hebben echter ook nadelen - waarvan ik de bekendste en belangrijkste noemde. Persoonlijk vind ik de passkeys van Android, iOS en iPadOS overall slechter dan mijn wachtwoordmanagers met domeinnaamcheck. Ik ben nog even voorzichrig met passkeys in KeePassDX en KeePassium, maar dat ziet er tot nu toe prima uit - en ik kan zelf backups maken van mijn passkeys (inclusief de private keys; bij Android en Apple passkeys zit ik vast aan hun clouddiensten).

M.i. is de stelling dat passkeys beter zijn dan wachtwoorden een te grote versimpeling van de praktijk. Graag laat ik de keuze aan u, de lezer. Daarbij peins ik er niet over om met de meeste security "experts" mee te blèren, bijv. dat, om veilig in te loggen, de fix voor zwakke wachtwoorden uit zwakke 2FA/MFA (SMS, TOTP, number matching) zou bestaan (zie bijv. https://csoonline.com/article/4147134 waarom dat bull shit is). Lees uzelf in en maak uw eigen keuzes!

gebruik wachtwoorden die je kan wegschrijven als een vraag en waarop het antwoorrd niemand anders weet dan jijzelf:
Voorbeelden:
Mijn eerste liefde, eerste auto die ik bezat, wie naast me in de 6-de klas lagere school( eerste 3 voornaam + eerste 3 achternaam) ik kan het zo moeilijk maken maar als je wilt.

je hoeft alleen maar de vraag op te schrijven, niemand die de juiste antwoorden weet.
als je familieleden vreest of mensen die jou wat beter kennen gebruik dan vragen waarop het antwoord iets is die werkelijk alleen jij weet.
ik gebruik een combinatie van deze vragen aan het einde van de vraag zet ik extra speciale leesteken.
ik streef naar wachtwoorden van 20+ tekens

Ik gebruik daarnaast een wachtwoord manager voor de meeste wachtwoorden, waarvan ik het belang wat minder 8 landen echt gevoelige wachtwoorden zoals bank DigiD etc.

voor digid heb je toch de digid app, vele malen beter dan wwoord

Ach natuurlijk: met Pasen bijna voor de deur wordt de passkey interessant! ;-)

Ik zou zeggen:
meer weten? Zie https://www.passkeys.com/nl/wat-zijn-passkeys

Daaruit:
Wat een gelul, precies de marketing talk die ik eerder noemde, gevolgd door de leugen dat passkeys alle online veiligheidsproblemen zouden oplossen. Biometrie is niet eens nodig, als een dief van jouw telefoon jouw ontgendelcode kent of kan raden, kan die dief (in de meeste gevallen) jouw passkeys gebruiken om in te loggen als zijnde jou.

Herinnert u zich deze campagne nog? Uit https://www.rijksoverheid.nl/ministeries/ministerie-van-justitie-en-veiligheid/het-verhaal-van-j-en-v/2025/samen-cyberweerbaarheid-stimuleren:
"Dubbel beveiligd" is niet per definitie "dubbel zo veilig": 2x zwak wordt nooit sterk (twee verschillende sloten op jouw fiets voorkómen niet dat deze door dieven in een busje wordt geladen). Omdat geen van beide authenticatiemethodes weerstand tegen iets slimmere phishing sites biedt, is ook dit pure misleiding.

Eveneens ordinaire marketing talk dus - om veel te zwakke wachtwoorden "op te peppen" met zwakke 2FA - zonder te wijzen op de bijbehorende risico's (phishing én account lockout).

Tevens uit https://www.passkeys.com/nl/wat-zijn-passkeys:
Niet immuun. Wel is een nepwebsite, waar passkeys op werken, veel lastiger te realiseren (voor cybercriminelen) dan voor nagenoeg alle andere vormen van 2FA (= een vorm van MFA). De meeste cybercriminelen zullen daarom inzetten op andere kwetsbare schakels in de keten.

Zie https://security.nl/posting/929755 hierboven (en desgewenst wat ik in 2023 schreef in https://security.nl/posting/798699) voor argumenten.

En, vóórdat u hierop reageert, lees eerst https://security.nl/posting/930017 (niet ver hierboven).

Maar wat adviseer je dan? Lang sterk wwoord met domijnnaam controle (en welke wwoordmanager doet dat dan) of een PassKey op in mijn geval Windows of een securitykey?(plus alternatief accountherstelmethode)?????

Mijn belangrijkste advies is om je goed in te lezen en zelf de risico's te overzien. Precies dat wordt gesaboteerd door malloten die uitsluitend de voordelen van een inlogmethode roeptoeteren waarbij een groot deel daarvan ook nog eens irrelevant of volslagen onzin is.

Ik was begonnen aan een nog uitgebreidere reactie, maar ik ben te moe en sowieso heeft dat niet zoveel zin onderaan een lange draad (zodra anderen reacties toevoegen verdwijnt mijn inspanning uit beeld). Wellicht begin ik binnenkort een nieuw topic hierover (dat niet alleen over passkeys gaat).

Het is onmogelijk om een generiek en betrouwbaar advies te geven. Als jij gevoelig bent voor social engineering en niet weet hoe je domeinnamen moet interpreteren, dan zouden passkeys wel eens de beste keuze kunnen zijn. Maar heel veel websites ondersteunen geen passkeys, daar moet je ook wat mee.

Als je maar weinig accounts hebt en heel goed bent in het onthouden van sterke (en dus unieke) wachtwoorden (ik ken niemand die daaraan voldoet), dan kun je mogelijk zonder wachtwoordmanager of notitieboekje. Als je zelden of nooit backups maakt, of niet weet (c.q. niet wil weten) hoe dat moet, vermijd dan wachtwoordmanagers en TOTP.

Als je niet uitsluit dat Google of Apple jouw account (cloudopslag), om wat voor reden dan ook, ooit zal afsluiten, gebruik dan geen Android/iOS/iPadOS passkeys (bovendien zijn de implementaties van beide fabrikanten buggy).

Aan de andere kant: als je sowieso nooit domeinnamen checkt als je een webpagina hebt herkend, niet weet hoe je domeinnamen moet interpreteren, dyslectisch of slechtziend bent, niet weet wat IDN's zijn en/of slecht bent in het onthouden van exacte domeinnamen, dan zijn passkeys en FIDO2 hardware keys (in Webauthn modus) mogelijk zó verstandig dat je de voornoemde risico's best kunt nemen.

Welke wachtwoordmanager je ook kiest, je zult de maker ervan moeten vertrouwen, ook dat deze niet de hele boel aan criminelen verkoopt of er zelf slechte cyberhygiëne op nahoudt (vaak is dit een gok, evt. gebaseerd op opgebouwde reputatie - maar ook dat kan slecht aflopen).

Kortom, het hangt van veel te veel factoren af om een generiek advies in een korte reactie te geven.

De meeste wachtwoordmanagers streven naar domeinnaam-check, maar onder Windows (waar ik elke dag een grotere hekel aan krijg) had je bij third party wachtwoordmanagers bij de meeste browsers een browser-plugin nodig (ik weet niet of deze situatie ondertussen verbeterd is).

Zoals ik eerder schreef: Andoid en iOS/iPadOS ondersteunen AutoFill, een onderdeel van die besturingssystemen die een (per OS) gestandaardiseerde interface tussen browsers, wachtwoordmanagers en biometrische bevestiging ondersteunt - los van welke wachtwoordmanager je gebruikt. In https://security.nl/posting/929784 staat onderin een link naar screenshots voor Android i.c.m. KeePassDX.

FIDO2 hardware keys (in Webauthn modus) kennen veel nadelen: prijzig, beperkt aantal accounts per key, je kunt er geen backups van maken maar ze wel eenvoudig kwijtraken, als je er (als backup) méér dan één hebt moet je zelf maar zien hoe je ze identiek houdt (als er thuis ééntje in een kluis ligt en je hebt op de andere een nieuw account toegevoegd, de discipline hebben om later ook die in de kluis te updaten), kwetsbaarheden (zelden te patchen) en veroudering, allerlei interfaces en mogelijke problemen bij draadloze communicatie. Ik vind ze onbruikbaar voor de meeste mensen, maar wellicht vorm jij een uitzondering.