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!