Ik vind het concept goed.
Maar de website pop-up van wil je inloggen met Google heel irritant.
Voelt net als een AD banner.

Ik hoop wel dat er een mogelijkheid komt dat je eigen password manager kan gebruiken ipv Google code.

Wel even vermelden dat dit alleen geldt voor de authenticatie op de betreffende web service, want
Dat houdt dus in dat de private keys wel ergens centraal worden opgeslagen zoals ook is te lezen in https://developers.google.com/identity/passkeys/supported-environments

No way, dat ik mijn accountgegevens ergens op een centrale plek zal opslaan. Niet voor niets gebruik ik een lokale password manager op dit moment (KeePass). Verder heb je dan dus een account bij de grote techbedrijven nodig, die nog meer inzicht krijgen in jouw inloggedrag over de verschillende web services heen. Ik maak alleen gebruik van lokale accounts om met mijn apparaten te werken, geen centraal beheerde.

Je ideeën over veiligheid zijn een beetje achterhaald. Je slaat je wachtwoorden nu ook op in een centrale kluis, alleen is die een stuk minder goed beveiligd dan de servers van MS/Google/Apple. De versleuteling van de kluis zelf is gelijk, dus dat maakt geen enkel verschil.

Het is een typische reactie van iemand die niet goed snapt hoe versleuteling werkt en zijn eigen kunnen op beveiligingsgebied, rijkelijk overschat.

dus dat houd in steeds weer inloggen met je smartphone....ik vind dit geen toegevoegde veiligheid .waarde eerde lastig..en is het nou extra beveiliging voor de buitenwereld.? Ik denk het niet dit verhaal speeld als je je laptop onbeheerd achter laat...wat je natuurlijk niet moet doen.........maar ik pas...no thanks

Dit staat toch volledig lost van passkeys?

Heel slim van deze bedrijven, die je dus verder de afhankelijkheid van diezelfde bedrijven in helpen, zodat je dus nooit meer om hen heen kan. Zeer onwenselijke en gevaarlijke ontwikkeling.

Wie fluit Google nu terug? Niemand, die Google nog in toom weet te houden.
En de twee grote investeringsmaatschappijen op aarde zagen dat het goed was.

Niet voor de eindgebruiker geldt dat overigens.
Dus zoveel mogelijk wegkoersen bij Google, Meta en andere BIG TECH multinationals.

Gedraag je individualistisch, scherp je IT-inzichten en bescherm je tegen deze digi-luciferiaanse singulariteit in opkomst.
Zo lang het nog kan, zo lang het nog gaat, weert het kwaad. Blijf zelf lezen, schrijven en rekenen.
Anders kun je je toekomstige lot wel op vijf vingers uittellen...you will be 'googled' big time.

#webproxy

Fijn dat je je reactie zo goed onderbouwd hebt (not). Ook heel fijn voor je dat jij je eigen kunnen mbt het beoordelen van andersmans kennis zo hoog hebt zitten ;)

Inhoudelij:
Zoals met alle beveiligingszaken is en blijft het een risico afweging tussen diverse aanvalsvectoren en -actoren en de kosten die het gebruik ervan met zich meebrengen. Hoe deze voor een individu uitpakken is toch echt een individuele afweging. Ook hoe bijv. het belang van privacy daarbij gezien wordt als een risico. Blijkbaar maakt MajorTom hier een eigen afweging in, die hij ook nog eens voorziet van argumentatie om zo enig inzicht in zijn afwegingen te geven. Doe er je voordeel mee, zou ik zeggen. Lijkt me beter dan hem zo maar af te serveren als 'zichzelf overschattend en niet goed van begrip'.

Ik weet heel goed hoe encryptie werkt, misschien ken jij het verschil niet tussen client side en server side encryptie,

Die private keys zullen "plain" (hooguit encrypted tijdens transport) naar de servers van Google en consorten gaan; misschien worden ze daar wederom versleuteld, maar de provider kan er gewoon bij, de encryptie key van de kluis aldaar is er immers bekend. De key waarmee de kluis wordt versleuteld blijft in mijn huidige situatie bij mij (i.e. client side encryptie), in de andere gevallen is die bekend bij de provider (of voor deze server side encryptie nu mijn eigen key of die van de provider wordt gebruikt maakt niet uit).

Het resultaat van beveiliging is gelijk qua encryptie van de kluis. Echter in mijn geval heb ik als enige de sleutel om bij de kluis te kunnen, in het andere geval weet de provider deze (ook). En laat ik nu deze providers niet echt vertrouwen dat deze integer hiermee om zullen gaan.

Ik vermoed dat Anoniem bedoelt dat hij niet wil dat de private keys bekend raken bij Google, maar ze in eigen beheer wil houden (net als ik). Het concept van passkeys is op zich goed (je krijgt uiteindelijk een verschillend keypair per service, dus een heel sterk "password"), maar de implementatie zoals voorgesteld door deze bedrijven vind ik niet ok.

Op dit moment heeft het voor mij weinig toegevoegde waarde (ik gebruik al andere credentiaals voor iedere service, waarbij ik de wachtwoorden laat genereren door mijn lokale wachtwoordmanager).

Niet een 'externe' partij moet voor jou "internetten", hetgeen Big Tech ook steeds meer wil gaan doen.
Ze moeten je fasciliteren en niet een soort van "gedogen als product".

Maar de wereld draait nu eenmaal op deze principes vanaf de vroegste tijden, lees Babylon.
De "kelipoth" kant wordt echter de laatste tijd steeds sterker.

#webproxy

De grote vraag is natuurlijk hoe veilig de passkeys lokaal op het device worden opgeslagen.

Misschien wordt het wel iets.

Zo krijgen deze bedrijven steeds meer macht over de gebruikers. Dit hoort een neutraal bedrijf te leveren. Dit verziekt de echte concurrentie.

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

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" (https://support.apple.com/guide/iphone/share-passkeys-passwords-securely-airdrop-iph0dd1796bb/ios). 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 aangekondigt [1], 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).

[1] https://tweakers.net/nieuws/203570/1password-krijgt-begin-2023-passkeys-voor-wachtwoordloze-authenticatie.html

Ik heb me er niet heel erg in verdiept - maar de hele omschrijving lijkt qua concept heel erg op SSH met agent-based login ?
Secret keys in de agent op een trusted device - wat hier dan de secure enclave is .

Ook die kun je (desgewenst versleuteld - met passphrase) backuppen.

Dank voor de reactie! Daar lijkt het inderdaad wel wat op.

Meer details over hoe passkeys werken geef ik in een (lange) post: https://tweakers.net/nieuws/204348/stabiele-chrome-versie-krijgt-ondersteuning-voor-op-fido-gebaseerde-passkeys.html?showReaction=18232048#r_18232048.

Handig. Al mijn private keys op een niet door mij beheerde server, service of 'secure enclave'. En dat laatste moet je dan maar gewoon vertrouwen (not).

Waardeloos concept. En doe maar gewoon niet dus.

Ik zou zeggen begin een bedrijf, als je denkt dat hierin een markt voor aanwezig is?

In die secure enclave moet dan of alle versleutelde passkeys en/of de masterkey zich bevinden waarmee de passkeys zijn versleuteld. Deze masterkey moet dan zijn afgeleid van de credentials waarmee je je uiteindelijk authentiseert of (zoals bijvoorbeeld bij LUKS gebeurt, je moet een additioneel password intypen bij opstarten van het device (of eerste toegang tot secure enclave)).

Als de masterkey wordt afgeleid van de credentials van het cloud account, dan is de masterkey in principe bekend bij de provider (onwenselijk).

Als de masterkey wordt afgeleid van een lokale toegangsaccessmethode dan zie ik het volgende probleem. Mocht deze lokale toegangsaccessmethode iets van een wachtwoord zijn (a la LUKS) dan geloof ik het wel, zij het dat je dan ditzelfde wachtwoord op al je devices moet gebruiken, al lijkt me wachtwoord authenticatie op een mobiel device niet gewenst/handig. Mocht het een PIN zijn, dan lijkt me dat niet goed genoeg: een brute force attack is dan mogelijk. Op grond van biometrische authenticatie lijkt het me niet mogelijk om daar eenduidig een masterkey uit te destilleren, aangezien die verificatie hiervan ook niet zo eenduidig is als bij bijvoorbeeld een wachtwoord (vgl FAR en FRR).

Als ik de informatie bekijk achter de URL die ik toevoegde, dan heeft Apple op dit moment nog geen synchronisatie tussen MacOS en IOS. Alleen tussen de IOS apparaten, waarbij de Apple iCloud Keychain wordt gebruikt voor opslag van de credentials. Om de KeyChain te unlocken wordt op MacOS het wachtwoord waarmee je op je device inlogt gebruikt. Hoe dit op IOS gebeurt zie ik niet zo snel, dus vraag ik me af waarmee deze keys dan worden versleuteld en hoe deze sleutel dus bekend is over meerdere devices.

Apple biedt een soort van Escrow functie, echter werkt deze met 2FA op basis van SMS. Dit biedt dan ook meteen een aanvalsvector doordat je op deze manier dan blijkbaar toegang kunt krijgen tot deze keys.

Eens. Eenmaal geautentiseert op het device biedt blijkbaar toegang tot deze passkeys, of dat dan een legitieme browser is of een kwaadaardige applicatie dat maakt dan geen verschil.

Websites kunnen niet zien hoe ik op mijn client device met passkeys omga (dat is altijd te faken vanaf dat device). Dus wanneer het protocol wordt ondersteund door de client applicatie gaat de server eea gewoon accepteren lijkt me.

(sorry dubbel)

In theorie is een masterkey mogelijk: als de passkey database uit versleutelde records bestaat (1 record per passkey) zou zo'n versleuteld record aan de secure enclave kunnen worden overgedragen en daarin worden ontsleuteld. Maar ik vermoed dat de hele passkey database onversleuteld in geheugen van de secure enclave staat.

Uit https://security.googleblog.com/2022/10/SecurityofPasskeysintheGooglePasswordManager.html:
Daaruit (en uit tekst elders in die pagina) leid ik het volgende af (ik kan dit fout hebben):

1) E2EE secrets (waaronder de passkeys van private keys) worden zelf niet versleuteld met de toegangscode (of veegpatroon/biometrische "neural hash") maar met één of meer sterke encryptiesleutels in (het Android equivalent van iPhones') secure enclave - kennelijk "trusted execution environment (TEE)" genaamd.

2) Die sterke encryptiesleutels lijken wel met slechts de potentieel zeer zwakke toegangscode te zijn versleuteld, dus dat zou het systeem alsnog zwak maken.

3) Gokje: denkbaar is dat de per user "end-to-end encryption keys" op Google servers in "secure hardware enclaves" worden opgeslagen en elk Android device (waarop een Google cloud-account is aangezet) een VPN-achtige tunnel daarmee opzet (met asymmetrische sleutels) waarover die "end-to-end encryption keys" worden uitgewisseld tussen server-side en client-side enclaves.

In genoemde pagina valt te lezen dat de toegangscode beschermd wordt tegen brute force, maar dat geldt natuurlijk alleen indien die code (of biometrie) in een Android device naar de locale "secure enclave" wordt gestuurd (niet bij offline attacks).

Ik heb geprobeerd (PDF download onderin https://support.apple.com/guide/security/welcome/web) Apple's strategie te begrijpen op o.a. dit punt, maar ik ben er nog niet uit. Ik weet ook niet of deze (mei 2022) voldoende actueel is en ook niet of zij zaken verzwijgen (als mijn gokje klopt haal ik dat ook niet uit Google's pagina).

Ik weet dus niet hoe het werkt, maar een aanvaller zal zowel toegang tot jouw cloud-account moeten hebben als een device-toegangscode kennen, uit genoemde Google pagina:

Ik vind de door Apple beschreven "rescue" methodes verre van duidelijk; als je ergens voor kiest wordt er gewaarschuwd dat andere methodes niet meer werken. Ook is mij niet duidelijk of je middels een "herstelcontact" ook weer toegang tot E2EE data in iCloud kunt krijgen. Termen als "herstelcode" en "herstelsleutel" worden door elkaar gebruikt. Een "erfeniscontact" heeft toegang tot jouw "account" - bedoeld wordt waarschijnlijk iCloud (niet E2EE data). Zodra foto's E2EE worden, kan zo'n erfenisaccount daar niet meer bij.

Sowieso lijkt Apple vooral vanuit het perspectief van het "Apple ID" account (iCloud en andere Apple clouddiensten) te denken, terwijl gebruikers in de eerste plaats vanuit hun device-account zullen redeneren.

Ik ben, denk ik, geen leek maar snap er al niets van. Ik mis het overzicht, bijv. middels plaatjes (leken gaan zeker die Apple platform security guide niet iezen, laat staan begrijpen). De kans op lock-out van jouw gegevens neemt rap toe met de nieuwe door Apple aangekondigde maatregelen (meer E2EE).

Ja dat kan wel, middels "attestation". Als ik met mijn iPhone (model SE uit 2016 met iOS 15.x) naar https://what-the-fido.sanford.io/ (niet te verwarren met stanford.edu) ga en wat klik, zie ik een 3-dagen geldig Apple signing certificaat met onder meer:

issuer-CN: "Apple WebAuthn CA 1"
subject-CN: lang hexadecimaal getal

gevolgd door een certificaat in CER (BASE64) formaat (ik vermoed dat dit hetzelfde cert is, maar weet dat niet helemaal zeker; het eerste "leesbare" cert zou een signing cert kunnen zijn voor het feitelijke attestation cert).

Hoe dan ook, als een website om attestation-data vraagt kun je de boel vermoedelijk niet eenvoudig belazeren.

Terzijde: in hoeverre deze WebAuthn-attestation gerelateerd is aan user-attestation om CAPTCHA's te kunnen overslaan (middels PAT's = Private Access Tokens) is mij nog steeds niet duidelijk (https://tweakers.net/nieuws/197728/cloudflare-brengt-private-access-tokens-uit-die-captchas-moeten-vervangen.html?showReaction=17603958#r_17603958).

Google werkt trouwens aan een extensie van passkeys waarbij er, per passkey, naast van een exportable private key, tevens sprake is van een device bound private key: zie "Passkeys and device-bound private keys" in genoemde Google pagina.

Waarom alle eieren in eenzelfde (Google-)mandje bewaren.

Niet slim, maar om andere redenen wel heel aantrekkelijk om te doen.

Je wordt er gratis aan/in-geholpen en eenmaal verkocht, ben en blijf jij het product, waar men aan verdienen kan.

Not watch your kicks, but watch your clicks.

luntrus