Computerbeveiliging - Hoe je bad guys buiten de deur houdt

Passkeys voor leken

06-06-2023, 17:43 door Erik van Straten, 16 reacties
Laatst bijgewerkt: 06-06-2023, 17:50
WAT ZIJN PASSKEYS?

1) Soort wachtwoord
Een passkey kunt u vergelijken met een ijzersterk (zeer lang, random - dus niet te raden, en wereldwijd uniek) wachtwoord.

2) "Passkeymanager" en "Passkeydatabase"
Al uw passkeys worden (elk met aanvullende gegevens) opgeslagen in een soort wachtwoordmanager, die ik hieronder passkeymanager noem. Effectief worden zij opgeslagen in een database die beheerd wordt door de passkeymanager, die ik passkeydatabase noem.

3) Koppeling met domeinnaam
Voor elk website-account waarvoor u een passkey toevoegt, wordt bij die passkey o.a. de domeinnaam (zoals www.security.nl) van de betreffende website opgeslagen (naast aanvullende gegevens zodat u kunt kiezen indien u meer dan één account op één website hebt).

4) https vereist en domeinnaam MOET kloppen
Zodra u op een website wilt inloggen met een passkey, verifieert de passkeymanager eerst dat er sprake is van een foutloze https-verbinding {a}, en zoekt daarna in de passkeydatabase naar de domeinnaam (van de website waar uw browser verbinding mee heeft).

Uitsluitend als een record met die domeinnaam gevonden wordt (mogelijk meerdere keren, namelijk als u meer dan één account heeft op die website), kunt u de bijbehorende passkey gebruiken om in te loggen. Hierdoor is het extreem lastig voor cybercriminelen om u op een nepwebsite te laten inloggen (waarna zij, met de door u verstrekte inloggegevens, als zijnde u kunnen inloggen op de echte website - en zo uw account kapen).

{a}: Bij een foutloze https-verbinding is het behoorlijk zeker dat a) uw browser verbinding heeft met de server waarvan de domeinnaam in de adresbalk van uw browser wordt getoond, en b) dat die verbinding versleuteld is.

5) U mag er zelf niet meer bij
Om u tegen zichzelf te beschermen (d.w.z. te voorkómen dat u wordt misleid en onbedoeld passkeys deelt met aanvallers), heeft u zelf nauwelijks of geen toegang tot de feitelijke passkeys, en zelfs vaak niet tot de versleutelde passkeydatabase (in zoveel mogelijk gevallen bevindt die database zich in een speciale chip, ook wel "secure -enclave" of TPM genoemd, bestemd voor de opslag en het verwerken van "sleutelmateriaal"; het betreft dus meestal geen "bestand" in de opslag op uw toestel of computer).

U kunt daar zelf dus niet of heel moeilijk back-ups van maken, en bent daarvoor afhankelijk van de back-up/synchronisatie-functionaliteit met de cloud-omgevingen van Apple, Google of Microsoft (totdat zij derde partijen, zoals Bitwarden en Lastpass, toegang geven tot passkey-functionaliteit).

6) Veel werkt nog niet
Er zijn nog niet veel websites die passkeys ondersteunen (daar zijn flinke aanpassingen voor nodig). En vooralsnog kunt u op een "platform" (besturingssysteem) zoals Android of iOS, uitsluitend gebruikmaken van passkeys in browsers van dat platform (resp. Chrome en Safari). Op Linux is er, voor zover ik weet, nog helemaal geen ondersteuning voor passkeys.

ZAKEN OM OP TE LETTEN

7) Ketens (met sommige schakels zwakker dan andere)
Nagenoeg elke vorm van beveiliging bestaat uit een keten. Ook passkeys zijn niet sterker dan de zwakste schakel, waaronder de schermvergrendeling van uw toestel - een methode die meestal ook wordt gebruikt voor het ontsluiten van een passkey tijdens inloggen op een webaccount, én dat van het (meestal) bijbehorende cloud-account met (verstopt) een kopie van de passkeydatabase (risico: een aanvaller die toegang krijgt tot uw cloud-account kan de passkeydatabase naar haar of zijn toestel synchroniseren).

Zorg dus voor sterke schermvergrendeling en een sterk wachtwoord op uw cloud-account!

8) Phishing-risico tijdens toevoegen passkey
Zodra passkeys meer ingeburgerd raken, neemt het risico op phishing-aanvallen toe: u ontvangt dan een nepmail die u uitnodigt om een passkey aan te maken op een account op een gegeven website (dit kan een pure gok zijn, wellicht heeft u helemaal geen account op die website). Als u op de link in de mail klikt, is de kans groot dat u op een nepwebsite uitkomt en moet inloggen. Klik niet op zo'n link!

Ga op de normaal door u gebruikte manier naar de website waarvan gesuggereerd wordt dat u vanaf nu met een passkey kunt inloggen, en kijk of dat zo is. Zo ja, dan kunt u -desgewenst- een passkey toevoegen. Of nog even afwachten i.v.m. mogelijke kinderziektes op de website - of het hele systeem met passkeys (dat effectief nog in ontwikkeling is).

Nb. Zeker ook indien u een nieuw account aanmaakt op een website, is het oppassen geblazen dat u dat op de juiste website (met de exact correcte domeinnaam) doet. Dit gold altijd al, maar hoe sterker de gebruikte authenticatie is, hoe lastiger het meestal is om te bewijzen dat het uw account is nadat het is gekaapt.

Ik verwacht overigens een toenemend aantal aanvallen waarbij u verleid wordt om een account aan te maken op een nepwebsite, waarna cybercriminelen dat -met uw gegevens- doen op de echte website. Zolang u via de nepwebsite blijft inloggen, werkt alles gewoon. Zodra er voor cybercriminelen voldoende te halen valt, sluiten zij uw toegang via hun website af en wijzigen evt. inloggegevens op de echte website - waarna u mag proberen te bewijzen dat het uw account is -op de echte website- wat het nooit geweest is (ook al staat het "op uw naam" - namen zijn zelden uniek).

9) Attestation: voor- en nadelen?
Webauthn (het protocol gebruikt door passkeys, maar ook FIDO2 hardware keys zoals Yubikey) ondersteunt, naast assertion (vaststellen dat niet iemand anders dan u inlogt op uw account) tevens attestation. Ik heb mijzelf nog niet uitgebreid in attestation verdiept (en vermoedelijk eigenaren van websites ook nóg niet), maar risico's m.b.t. privacy en uitsluiting liggen hierbij op de loer: er kan worden gecheckt of uw toestel, alsmede daarop aanwezige software, en wellicht uw gedrag en/of reputatie, aan door de eigenaren van servers te stellen eisen voldoen.

10) Alternatieve inlogmethodes
Vaak kan men op méér dan één manier inloggen op een webaccount (er zijn dan parallelle ketens die zelden even sterk zijn). Meestal zult u, in plaats van met een passkey, ook nog met een wachtwoord (al dan niet gecombineerd met en extra factor, zoals een via SMS ontvangen code, of een code uit een "authenticator" app) op een account kunnen inloggen. Een sterke passkey helpt natuurlijk niet tegen een zwak alternatief.

Advies: vervang meteen uw wachtwoord (alleen nodig bij problemen met of verlies van uw passkey; ook op de server kan iets misgaan daarmee) door een sterk en uniek exemplaar dat u opslaat in een aparte wachtwoordmanager of opschrijft in een boekje o.i.d. (dat u bewaart op een plaats die niet snel door onverhoopte inbrekers wordt gevonden). Hou ook rekening met het risico op account lock-out: verzeker uzelf ervan dat u zo'n wachtwoord kunt terugvinden, maar ook dat uw passkeys worden geback-upped!

11) Mogelijk extra wachtwoord
Ik sluit niet uit dat er systemen komen (of al bestaan) waarbij u (naast een PINcode of wachtwoord voor apparaattoegang/schermvergrendeling en inloggegevens voor uw cloud-account) een aanvullend wachtwoord nodig heeft voor de versleuteling van de passkeydatabase (en evt. andere te beveiligen gegevens). Kies ook daar een sterk wachtwoord voor en bewaar dat op een veilige plaats.

Normaal gesproken wordt dat wachtwoord opgeslagen in eerdergenoemde speciale chip en is beschikbaar zodra u het scherm van uw toestel ontgrendeld heeft of bent ingelogd op uw PC; u heeft het meestal alleen nodig als uw toestel gestolen wordt of ineens helemaal defect raakt.

Het is belangrijk om hier een sterk wachtwoord voor te kiezen (veel sterker dan de ontgendelcode van uw toestel) omdat versleutelde bestanden die in verkeerde handen vallen zichzelf niet kunnen beschermen tegen voortdurend herhaalde ontgendelpogingen met ooit gelekte of opeenvolgend gegenereerde wachtwoorden (toestellen voegen vaak steeds langere pauzes in voordat men opnieuw kan proberen in te loggen).

12) Veel accounts zonder administratie
Hoe eenvoudiger het wordt om een webaccount aan te maken, hoe sneller u daartoe verleid zou kunnen worden. Ik dwing mijzelf ertoe om elk webaccount dat ik aanmaak, goed te administreren (in elk geval in een overzichtelijk ingedeelde wachtwoordmanager, en vaak maak ik ook screenshots). Als u, na het verlies of diefstal van een toestel met daarop passkeys (en u, bijv. op vakantie, geen werkend apparaat met een kopie van alle passkeys heeft), niet weet op welke websites u allemaal accounts heeft zodat u deze kunt (proberen te) blokkeren, kan dat een risico betekenen.

Het zal van de door u gebruikte "passkeymanager" afhangen hoe eenvoudig of moeilijk u een overzicht kunt verkrijgen van alle websites met accounts. Helaas bestaat er, zoals voor uw bank bij verlies van uw bankpas, geen telefoonnummer dat u kunt bellen om in één keer alle inloggegevens op een toestel te (laten) blokkeren. U doet er in elk geval verstandig aan om, op afstand, gegevens op uw toestel(len) te kunnen wissen.

13) Vendor lock-in
Het zit er voorlopig niet in dat u passkeys aangemaakt onder iOS/iPadOS, Android of Microsoft Windows, met een ander platform kunt uitwisselen (bijv. tussen een Android smartphone en een iPad). U zou dan wel kunnen proberen in te loggen op apparaat 1 door apparaat 2 (met passkeys) draadloos te koppelen (NFC of Bluetooth) en/of QR-codes te scannen. Dat klinkt allesbehalve risicoloos en is, neem ik aan, een hoop gedoe. Wellicht dat wachtwoordmanagers (zoals Bitwarden en 1Password) hier verbetering in aanbrengen - zodra deze passkeys (mogen) ondersteunen, maar dan zit u mogelijk vast aan zo'n leverancier (denk aan mogelijke prijsverhogingen of datalekken waardoor u zou willen overstappen). Het hangt er ook vanaf of u in de toekomst mogelijk wél directe toegang krijgt tot uw feitelijke passkeys (effectief de private key van elke passkey).

14) Verplaatsen van aanvallen
Naarmate we het aanvallers moeilijker maken om onze inloggegevens van servers of "onderweg" (bijv. middels een nepwebsite) te kapen, zal het aantal "client-side" aanvallen, dus op uw toestel(len), PC('s), browsers en andere software, toenemen. Daar komt bij dat er, voor aanvallers, steeds meer digitaal "te halen valt" via of vanaf genoemde apparaten van u. Naarmate dat risico toeneemt, zal -in uw eigen belang- ook uw "cyberhygiëne" moeten toenemen. Maar ook het aantal uitnodigingen om en account aan te maken op een nepwebsite zou kunnen toenemen (zie de tweede paragraaf van punt 8).

NIET VOOR LEKEN
Het vaak genoemde "grote voordeel" van passkeys, dat deze van asymmetrische cryptografie gebruikmaken, is m.i. sterk overdreven. Als er een https-verbinding bestaat met de juiste website, boeit het niet of er een shared secret over de lijn gaat of signed data. Indien een aanvaller via een BGP-hijack, middels schrijftoegang tot een DNS-record of via een op andere wijze onterecht uitgegeven certificaat een nepwebserver met de domeinnaam van de echte website *tussen* de client en de echte webserver kan plaatsen, bestaat er ook geen verschil tussen een shared secret of signed data: de aanvaller logt in op de echte site als ware hij of zij de gebruiker van de client.

Een passkey is een sterk authenticatiemiddel omdat, in de eerste plaats, software de dommeinnaam checkt (punt 4 hierboven) en in de tweede plaats, dat een de public key (op de server) effectief een ijzersterk wachtwoord is (punt 1).

De "passkeymanager" waar ik het (vereenvoudigd) over heb bestaat uit software verdeeld over meerdere "partijen": draaiend op de server, aangeleverd door de server aan de browser, functionaliteit in de browser, in het besturingssysteem en vaak in hardware.

DISCLAIMER
Ik schrijf dit naar eer en geweten, op basis van mijn huidige kennis. Dreigingen veranderen echter voortdurend; we kunnen het ons niet veroorloven om onze inzichten niet bijtijds aan te passen. Deze posting kan ik, 1 uur na plaatsing, echter niet meer wijzigen. Kijk dus hieronder voor eventuele aanvullingen en/of correcties.
Reacties (16)
06-06-2023, 22:32 door Anoniem
Erik,

Wederom bedankt, weer wat geleerd!

Thanks!
07-06-2023, 07:49 door Anoniem
Dank je wel Erik.

Mooi leesbaar en begrijpelijk.

Noob
07-06-2023, 09:58 door Anoniem
Zeer waardevolle bijdrage Erik, dank voor de heldere uitleg!

Zou je passkeys zelf gaan gebruiken?
07-06-2023, 10:15 door Anoniem
En dit voor de gemiddelde burger, leek, huismoeder, huisvader,
knettergek worden mensen hier van
Al dat gedoe me wachtwoorden boekjes om in op te schrijven, dan weer op een geheime plaats opbergen
Wat een vreselijke wereld die digide wereld
MIJN overheid MIJN zorgtoeslag MiJN toeslagen MIJNzorg< MIJN MIJN MIJN MIJN =====OVERHEID
Allemaal verschillende portalen ook nog
07-06-2023, 12:10 door Anoniem
Door Anoniem: En dit voor de gemiddelde burger, leek, huismoeder, huisvader,
knettergek worden mensen hier van
Al dat gedoe me wachtwoorden boekjes om in op te schrijven, dan weer op een geheime plaats opbergen
Wat een vreselijke wereld die digide wereld
MIJN overheid MIJN zorgtoeslag MiJN toeslagen MIJNzorg< MIJN MIJN MIJN MIJN =====OVERHEID
Allemaal verschillende portalen ook nog
Stom geluol, alle overheid sites log je in met DigiD !!!!
07-06-2023, 15:11 door Erik van Straten - Bijgewerkt: 07-06-2023, 15:37
Door Anoniem: Zou je passkeys zelf gaan gebruiken?
Ik denk dat ze vooral handig zijn voor minder digitaalvaardige mensen, maar ik ga ze zeker verder testen (ik probeer vanalles, de laatste weken wachtwoordmanagers op iOS en Android die ook de domeinnaam checken).

Door Anoniem: En dit voor de gemiddelde burger, leek, huismoeder, huisvader, knettergek worden mensen hier van
Al dat gedoe me wachtwoorden boekjes om in op te schrijven, dan weer op een geheime plaats opbergen
Wat een vreselijke wereld die digide wereld
MIJN overheid MIJN zorgtoeslag MiJN toeslagen MIJNzorg< MIJN MIJN MIJN MIJN =====OVERHEID
Allemaal verschillende portalen ook nog
Je hebt absoluut een punt.

Voor mij persoonlijk is het een groot dilemma: moet ik mijn kennis delen met minder digitaalvaardigen - met als potentieel gevolg dat digidrammers nog een tandje bijzetten?

Of doe ik er netto toch goed aan om die minder digitaalvaardigen te helpen?

Is de concentratie van inloggegevens in een "passkeymamager" en/of wachtwoordmanager écht beter dan mensen maar laten tobben met meerdere waardeloze wachtwoorden?
07-06-2023, 15:19 door Erik van Straten
Dank voor de reacties!

Bij punt 1 had ik, achteraf bezien, kunnen toevoegen dat u dat "ijzersterke unieke wachtwoord", per web-account, nooit hoeft over te tikken (laat staan zelf te onthouden).

Het idee achter passkeys (en wachtwoordmanagers in het algemeen) is dat u het onthouden van sterke wachtwoorden delegeert naar uw toestel(len) en software daarop, of naar een online wachtwoordmanager.

Terzijde / merk op: dat "delegeren" is natuurlijk niet zonder risico's voor u: als een aanvaller toegang krijgt tot één van uw toestellen, of een cloud-back-up daarvan op haar of zijn toestel kan "terugzetten" (restoren), dan heeft u in één keer een enorm probleem.

Het alternatief, voor elk van de vaak vele accounts, zelf een uniek sterk wachtwoord {a} onthouden, is onmenselijk en kansloos. Mits je goed nadenkt en de juiste maatregelen neemt, lijkt delegeren toch het beste van twee kwaden.

{a}: In https://security.nl/posting/798727 beschreef ik gisteravond wat T-Mobile.nl onder een "sterk wachtwoord" verstaat (dat is om te janken).

Als u, met een passkey, wilt inloggen op een web-account, ontsluit u de juiste inloggegevens voor die site door uw passkeymanager (of wachtwoordmanager) te "ontgrendelen".

Bij passkeys gebeurt dat meestal door het invoeren van een PINcode of (optioneel, in plaats van een PINcode) door het laten scannen van uw gezicht of een vingertopje (bij een wachtwoordmanager moet u meestal een wachtwoord invoeren, alhoewel ook zij steeds vaker een PINcode of biometrie ondersteunen om dat -dan verstopte- wachtwoord te ontsluiten).

Schematisch ziet dat er, met zowel een smartphone als een tablet (die onderling worden gesynchroniseerd), uit als volgt:
Passkey VRIJ- | Feitelijk inloggen
GEVEN om in | op webservers
te loggen op | gebeurt met (voor de
webservers | user onzichtbare)
| passkeys

PINcode
of .---. user-ID +
Face-ID | ° | passkey 1 .----------.
•>| |>• • • • • •>| web- |
• | | •>| server 1 |
• '---' • '----------'
• ^ •
• | back-up + •
• | synchr. •
• v •
• .--------. • user-ID +
• | cloud- | • passkey 1
O >• | server | •
/|\>• '--------' •
/ \ • ^ •
• | back-up + •
• | synchr. •
• v •
• .----------. •
• | |>• •
•>|o | .----------.
PINcode | |> • • •>| web- |
of '----------' user- | server 2 |
vingerafdruk ID + '----------'
passkey 2
Indien de passkey-gegevens volledig zijn gesynchroniseerd tussen uw twee apparaten (via de cloudserver) kunt u natuurlijk ook met uw smartphone inloggen op "webserver 2" (dat laten zien in het plaatje werd te rommelig).

Voor techneuten: in de praktijk zit hier meestal minstens één extra stap tussen: met de PINcode of biometrie wordt één sterk wachtwoord (dat u niet in alle gevallen te weten komt), en dat meestal is opgeslagen in een secure enclave of TPM op uw apparaat, vrijgegeven. Dat wordt dan vervolgens gebruikt om toegang te krijgen tot de passkeydatabase, of database van een reguliere wachtwoordmanager.

Onthouden (of opschrijven en onthouden waar)
In de praktijk moet u ten minste de volgende geheimen zelf onthouden (ik hoop dat ik niks vergeet):

1) Ontgrendelcode: PINcode of wachtwoord (bij voorkeur geen veegpatroon) per apparaat. Desgewenst kunt u op alle apparaten dezelfde code gebruiken. Het m.i. grootste risico hierbij is dat iemand, die uw code afkijkt (wat veel lastiger is bij het gebruik van biometrie), op al uw apparaten kan inloggen.

Maar als die apparaten sowieso (deels) worden gesynchroniseerd, maakt het nauwelijks uit of een kwaadwillende toegang op één van uw, of al uw, apparaten kan krijgen. Dit risico lijkt mij zeer klein in verhouding tot het gebruiksgemak plus het lagere risico op vergeten van zo'n PINcode.

2) Een uniek sterk wachtwoord voor het cloud-account van uw apparaten: uw Apple-ID, gmail-adres of Microsoft account. Indien van uw toestel(len) back-ups naar cloud-server worden gemaakt en/of gegevens worden gesynchroniseerd, is het van essentieel belang dat u dit account grondig beveiligt met een sterk wachtwoord en eventueel 2FA. Genoemde cloudproviders hameren hier ondertussen redelijk op, en proberen zoveel mogelijk te voorkómen dat u dit wachtwoord vaak moet invoeren (met het risico op het vergeten daarvan).

Indien u, bijvoorbeeld als gevolg van diefstal, defect raken, inbraak, brand, omgeslagen boot etc. de toegang tot uw toestel (of alle gekoppelde toestellen) verliest, dan volgt (onnodig) vaak een tweede drama: naast dat u uw toestel(len) kwijt bent, blijkt u ook niet meer te kunnen inloggen op uw cloud-account (onder meer nodig om een back-up op een nieuw toestel "terug" te kunnen zetten).

Stelt u zich voor, aan de hand van bovenstaand "plaatje", dat u beide apparaten kwijt bent: hoe logt u dan in op uw cloud-account (en alle andere web-accounts)? Nb. om deze reden kunt u NIET uitsluitend een passkey gebruiken voor dit account: u heeft dan een toestel met die passkey nodig (kip/ei probleem). Denkbaar is wel dat u hier zowel een passkey als een recovery-code (zie punt 3 hieronder) voor heeft.

Tip: probeer in te loggen op de website van uw cloud-account vanaf een veilig maar niet gekoppeld apparaat, en kijk waar u tegenaan loopt! (Denk aan een SMS ontvangen op een telefoonnummer waar u op dat moment niet 'bij kunt"). Herhaal dit regelmatig, want op het gebied van inloggen verandert er voortdurend vanalles op het internet.

Voorkom dat u met account-lockout te maken krijgt. Mede omdat cybercriminelen toegang tot uw cloud-account proberen te krijgen door te claimen dat zij u zijn, en hun toestel is gestolen, zijn de "big tech" providers er meestal niet happig op om u te helpen: in zo'n situatie kunnen zij u onvoldoende betrouwbaar onderscheiden van een cybercrimineel. Zie ook punt 3 hieronder.

3) Een "recovery-code" voor het cloud-account van uw apparaten (herstelcode, soms "rescue-code" genoemd): laat deze aanmaken en bewaar deze op een veilige en "terugvindbare" plaats. Overweeg ook een toegangsmogelijkheid voor nabestaanden of voor het geval dat u om andere redenen (tijdelijk) "handelingsonbekwaam" wordt.

4) Een uniek sterk wachtwoord op uw e-mailaccount (indien dit niet tevens uw cloud-account is): omdat uw e-mailaccount in bijna alle gevallen voor wachtwoord-herstel wordt gebruikt, is het superbelangrijk dat kwaadwillenden geen toegang krijgen tot uw mailbox.

Als hen dat wel lukt, kunnen zij op websites waar u accounts heeft, aangeven dat zij "uw wachtwoord zijn vergeten", waarna zij, via een link in de mail die men in zo'n situatie meestal ontvangt, toegang krijgen tot dat webaccount. Daarna kunnen zij uw wachtwoord (en andere gegevens) wijzigen.

Nb. indien uw e-mailaccount niet tevens uw "toestel-cloud-account" is, kunt u dit wachtwoord natuurlijk in een wachtwoordmanager opslaan (of, zodra dat mogelijk is, daar een passkey voor gebruiken).

5) Mogelijk een uniek sterk wachtwoord voor versleuteling van back-ups in de cloud: bijv. Apple gebruikt een mij onbekende methode om de meest gevoelige informatie (o.a. "keychain") op uw iPhone of iPad versleuteld in de "iCloud" te back-uppen.

Apple (en de NSA etc.) hebben potentieel toegang tot uw iCloud-account (waarop u inlogt met uw Apple-ID). Apple kan ook uw wachtwoord daarvoor achterhalen (dat voert u immers in op hun server). Het enige dat Apple (naar eigen zeggen) niet kent, is de PINcode voor uw iDevice(s) - maar dat is meestal veel te zwak voor veilige versleuteling van data.

Omdat het mogelijk moet zijn om een back-up te kunnen "terug" zetten op een nieuw toestel (na verlies van alle oude toestellen), kan er geen gebruik worden gemaakt van een sterk wachtwoord opgeslagen in een secure (hardware) enclave op uw verloren gegane toestel(len). Als ik het goed begrijp heb je daarom, voor de volledig "E2EE" back-ups die Apple recentelijk introduceerde, een aanvullend "lokaal" sterk wachtwoord nodig (ik heb dit zelf nog niet getest).

Nb. Apple waarschuwt er (terecht) voor dat, indien u van E2EE back-ups gebruik maakt, zij u op geen enkele manier meer kunnen helpen indien u zo'n wachtwoord vergeet. Deze E2EE back-ups lijken mij daarom hooguit uit iets voor nerds of mensen die ernstig gevaar lopen (zoals sommige journalisten).

6) Optionele wachtwoordmanager: gebruik een lang uniek sterk wachtwoord voor het versleutelen van (de database van) uw wachtwoordmanager - vooral als de database in de cloud en/of op zelf (niet sterk versleutelde) eigen media wordt geback-upped.

Biometrie
Hier valt veel over te zeggen maar deze posting is alweer erg lang. Wellicht kom ik hier in een andere bijdrage op terug.

Kortom:
Beveilig uw toestel(len), cloud-account(s) en e-mailaccount grondig. Of we het nu leuk vinden of niet: in rap toenemende mate vertegenwoordigen onze digitale apparaten en cloud-accounts onze identiteit, waardoor de waarde ervan -ook voor cybercriminelen- snel stijgt.

Vangnetten voor slachtoffers van identiteitsfraude zijn er nauwelijks, en als ze bestaan zijn ze onvoorspelbaar qua betrouwbaarheid. Ook rechters oordelen dat het uw eigen verantwoordelijkheid is om uw digitale identiteit goed te beschermen; big tech heeft zich uitgebreid ingedekt tegen eventuele aansprakelijkheid (voorbeeld: https://www.security.nl/posting/798595/T-Mobile+hoeft+diefstal+van+17_500+euro+aan+crypto+na+sim-swap+niet+te+vergoeden).

Denk na over, en test, of u slachtoffer van account-lockout (buitensluiten) zou worden - vergelijkbaar met de voordeur achter u dichttrekken terwijl de sleutel binnen ligt.
07-06-2023, 15:27 door Erik van Straten - Bijgewerkt: 07-06-2023, 15:29
(sorry dubbel)
08-06-2023, 09:38 door majortom - Bijgewerkt: 08-06-2023, 09:40
Door Erik van Straten: WAT ZIJN PASSKEYS?
[...]
5) U mag er zelf niet meer bij
Om u tegen zichzelf te beschermen (d.w.z. te voorkómen dat u wordt misleid en onbedoeld passkeys deelt met aanvallers), heeft u zelf nauwelijks of geen toegang tot de feitelijke passkeys, en zelfs vaak niet tot de versleutelde passkeydatabase (in zoveel mogelijk gevallen bevindt die database zich in een speciale chip, ook wel "secure -enclave" of TPM genoemd, bestemd voor de opslag en het verwerken van "sleutelmateriaal"; het betreft dus meestal geen "bestand" in de opslag op uw toestel of computer).
Dit lijkt me sterk. Ik verwacht dat een TPM hooguit wordt gebruikt als een soort root-of-trust. De capaciteit is er niet in een TPM om daar alle (wellicht honderden/duizenden) passkeys in op te slaan (zelfs een YubiKey device heeft maar plaats voor 25 passkeys https://www.yubico.com/blog/a-yubico-faq-about-passkeys/. Ik verwacht een principe dat de master key (MKEY) in de TPM zit, waarmee de key waarmee de password database is versleuteld (EKEY) zelf is versleuteld.

MKEY in TPM
EKEY is versleuteld met MKEY
Database is versleuteld met EKEY
08-06-2023, 10:21 door Anoniem
Het grote probleem is dat het er helemaal vanuit gaat dat er een 1:1 relatie is tussen fysiek device en gebruiker, en
daarmee account(s). "Windows Hello" is een implementatie hiervan, en je ziet dan ook dat men dat propageert als
"access to all your accounts from your device".
Alsof iedereen maar 1 device gebruikt.
Heb je een laptop die je overal mee naar toe sjouwt, mooi. Maar werk je op allerlei computers en wil je daar overal
toegang hebben tot je accounts, dan is het pech gehad...
Bij "Windows Hello" moet je op ieder nieuw device waarop je inlogt opnieuw een enroll doen waarbij je dan dus weer
een pincode moet opgeven, je vinger scannen, je gezicht laten fotograferen, enz enz. Dan is uiteindelijk alles in de
TPM van die computer opgeslagen en kun je daar makkelijk (en kennelijk veilig) op werken.
Maar stel je nu eens een kantoor voor met 50 "flexplekken" met ieder een desktop PC waar je in principe iedere dag
op een andere plek zou kunnen zitten. Dan is dat niet zo leuk meer.
08-06-2023, 15:10 door Erik van Straten
Door Anoniem: Het grote probleem is dat het er helemaal vanuit gaat dat er een 1:1 relatie is tussen fysiek device en gebruiker, en daarmee account(s). "Windows Hello" is een implementatie hiervan, en je ziet dan ook dat men dat propageert als "access to all your accounts from your device".
Zelf heb ik Windows Hello nog nooit gebruikt; ik vertrouw het onvoldoende.

Door Anoniem: Alsof iedereen maar 1 device gebruikt.
Het grote verschil tussen bijv. Yubikeys en Passkeys, is dat Passkeys tussen apparaten van gebruikers mogen en kunnen worden uitgewisseld - tenzij een passkey als "device-bound" (apparaatgebonden) is "getagged" (gelabeled).

De private keys van WebAutn sleutels (effectief ook passkeys) in FIDO2-capable hardware keys (zoals Yubikey en Google Titan) zijn, voor zover ik weet, in alle gevallen "device-bound", dus non-exportable. Daardoor kun je er geen back-up van maken. Om het risico op verlies en defect raken te verkleinen, luidt het algemene advies om minstens twee hardware keys te bezitten, en voor elk webaccount een (unieke) "passkey" op minstens twee van je hardware keys aan te maken. Dat gedoe, samen met de prijs en de grote kans op ergens vergeten van zo'n ding, leidt ertoe dat FIDO2 hardware keys ongeschikt zijn voor de meeste stervelingen.

Qua veiligheid worden hardware keys ook nog eens overschat, want een voorwaarde voor security is dat het apparaat van de gebruiker niet is gecompromitteerd.

In het "plaatje" in https://security.nl/posting/798797 heb ik geprobeerd uit te beelden hoe de synchronisatie werkt tussen meerdere apparaten van één gebruiker. Echter, voorlopig niet tussen apparaten met verschillende besturingssystemen.

Door Anoniem: Heb je een laptop die je overal mee naar toe sjouwt, mooi. Maar werk je op allerlei computers en wil je daar overal toegang hebben tot je accounts, dan is het pech gehad...
Klopt, passkeys zijn hooguit handig op persoonlijke apparaten.

Persoonlijk zou ik overigens zo weinig mogelijk geheimen en andere privacygevoelige gegevens op "flex-plek-computers" willen achterlaten, want in elk geval beheerders kunnen daar vaak bij (ik weet niet hoe populair vaste computers op flexplekken nog zijn, maar het zou mij verbazen als dat concept niet ruim over het hoogtepunt heen is).

Alternatieven zijn in elk geval:
• Hardware keys;
• Smart cards;
• Wachtwoordmanagers;
• Passkeys op "eigen" (kan door de baas betaald zijn) smartphone die je draadloos koppelt met de PC.

Door Anoniem: Bij "Windows Hello" moet je op ieder nieuw device waarop je inlogt opnieuw een enroll doen waarbij je dan dus weer een pincode moet opgeven, je vinger scannen, je gezicht laten fotograferen, enz enz. Dan is uiteindelijk alles in de TPM van die computer opgeslagen en kun je daar makkelijk (en kennelijk veilig) op werken. Maar stel je nu eens een kantoor voor met 50 "flexplekken" met ieder een desktop PC waar je in principe iedere dag op een andere plek zou kunnen zitten. Dan is dat niet zo leuk meer.
Nee, maar Windows Hello lijkt mij niet ontworpen voor die situatie.

Nb. ik heb nog behoorlijk grote twijfels over passkeys (en ontdek telkens -voor mij nieuwe- nadelen). Zodra de meeste kinderziektes eruit zijn en de voordelen opwegen tegen de nadelen, zijn die voordelen vooral voor gebruikers van YOD (uit BYOD) - dus niet voor flex-plek-computer-users.
08-06-2023, 15:17 door Anoniem
Vanuit de High Tech Campus is de oplossing MindYourPass bedacht die ook unieke passkeys per website heeft alleen worden deze elke keer opnieuw gegenereerd. Zij staan dus niet eens opgeslagen in een database en kunnen dus niet lekken.
08-06-2023, 15:41 door Anoniem
Door Erik van Straten:
Nee, maar Windows Hello lijkt mij niet ontworpen voor die situatie.
Het probleem is dat heel Microsoft niet meer ontworpen is voor die situatie.
Alles wat Microsoft tegenwoordig maakt (niet alleen Windows maar hun hele applicatie gebeuren) gaat er vanuit
dat je "your device" hebt.
Terwijl dat vroeger allemaal zo mooi werkte in een domain met roaming profiles... toen kon je overal inloggen en
had je al je gegevens bij je.
08-06-2023, 17:59 door Erik van Straten
Door majortom:
Door Erik van Straten: WAT ZIJN PASSKEYS?
[...]
5) U mag er zelf niet meer bij
Dit lijkt me sterk.
Wellicht dat dit op een rooted Android of iOS/iPadOS device mogelijk is, maar in elk geval kunnen doorsnee users voorlopig niet bij hun passkeys.

Eerder vandaag heb ik op mijn Google Pixel 6 Pro smartphone, vanuit Google Chrome, mijn passwords en passkeys geëxporteerd met als resultaat letterlijk het volgende CSV-bestand:
name,url,username,password,note
passkeys-demo.appspot.com,,,,
passkeys-demo.appspot.com,,,,
Dit was eind van de ochtend nadat ik gisteravond (ok na middernacht) op https://passkeys-demo.appspot.com/, voor zowel de gebruikersnaam "test" als "origami_tester" (die niet eens worden genoemd in de CSV), elk één passkey had aangemaakt (meer dan 1 per account per device staan die site en/of mijn smartphone niet toe).

Over die Passkeys-testsite: De link hiernaar vond ik in https://developers.google.com/identity/passkeys.

Ik logde bewust in als user "test" omdat ik verwachtte dat dit account al zou bestaan, en ik dus iets anders zou moeten verzinnen - maar zo werkt deze site niet: iedereen kan inloggen als "test" - waarbij het wachtwoord niet uitmaakt.

De kans is groot dat je, na inloggen als user "test" (vóórdat je zelf überhaupt een passkey hebt aangemaakt), al meerdere passkeys genoemd ziet worden. Op het moment van schrijven zijn dit (nummering toegevoegd door mij):
Your registered passkeys:

1) Android
2) Android (Erik)
3) Apple Mac
4) 20230608_0147

Die tweede en vierde zijn van mij; als je de naam niet wijzigt (wat iedereen wel kan, net als deleten van public keys), staat daar dus de naam van het gebruikte platform).

Pas als je daaronder op de rode knop "CREATE A PASSKEY" drukt, wordt een passkey voor die site met dat account aangemaakt op jouw toestel (tenzij er al een passkey bestaat op jouw toestel voor account "test" op die site) en de public key op de server opgeslagen.

Als je wilt testen of je over een week nog kunt inloggen met jouw passkey, doe je er verstandig aan om dat onder een accountnaam te doen die anderen niet raden (om vervolgens jouw public key te deleten.

Om verder mijn belevenissen te delen: begin van de middag heb ik de sync van Chrome met mijn Google account beveiligd met een passphrase, zodat er niet uitsluitend sprake is van transportbeveiliging (https), maar Google medewerkers geen toegang meer hebben tot door Chrome gesynchroniseerde gegevens - waaronder eventuele wachtwoorden die ik opsla in "Google Password Manager" en mogelijk private keys horende bij mijn passkeys.

Die passphrase is overigens wat ik bedoelde achter punt "5)" in https://security.nl/posting/798797 hierboven.

Vervolgens heb ik getest wat er gebeurt als ik die passphase wijzig. Kennelijk moet dat in https://chrome.google.com/sync, onderin staat:
This will clear your Chrome data from your Google Account.
This won't clear any data from your devices.
This will also remove your sync passphrase. You can create a new passphrase.

[CLEAR DATA]
Na op de knop "CLEAR DATA" te hebben gedrukt kon ik een nieuwe passphrase invoeren. So far, so good.

Maar toen bleken beide passkeys voor passkeys-demo.appspot.com te zijn verdwenen van mijn smartphone!

Lekker betrouwbaar allemaal, gelukkig niet-boeiende testdata in dit geval.

En toen ik daarna met Chrome op mijn Google account probeerde in te loggen, kon dat ineens ook niet meer met een passkey (die wel bestond, maar niet terechtkomt in de CSV - zijn er 2 soorten passkeys in Android?). Sterker, ik moest meteen mijn Google wachtwoord wijzigen - en dat zonder dat ik mijn oude wachtwoord moest invoeren (scary!).

Vervolgens mocht ik niet mijn oude wachtwoord hergebruiken - dat (vermoedelijk een one-way afgeleide daarvan) Google dus nog wel kende. Dus maar 1 karakter gewijzigd, dat accepteerde Google wel.

Als test heb ik, nu bewust, voor wachtwoord wijzigen gekozen - nu wilde Google ineens "Use your passkey to confirm it’s really you" en moest ik mijn vingerafdruk gebruiken. Daarna lijkt die vingerafdruk helemaal niet meer nodig, zelfs niet na een reboot: als ik met Chrome de link https://myaccount.google.com/ open, "zit ik" meteen in mijn account (ik heb niet onderzocht of het hierbij om auth met een passkey gaat - dan zonder vingerafdruk - of om een langdurig geldige session cookie). Ik kan nergens een "Log out from Google" o.i.d. vinden.

Wel positief: als ik https://passwords.google.com/ nu open, wordt Chrome doorgestuurd naar https://passwords.google.com/error/sync-passphrase waarin onder meer staat:
Password Manager

Google can't check your passwords for security issues because you set up a passphrase to encrypt your passwords in your Google Account. This keeps the data private to you.
Learn more.

Affijn, eenvoudig en risicoloos is het allemaal niet, in elk geval niet als je van de standaard (riskante?) paden afwijkt. Bovendien is het volstrekt onduidelijk wat er "onder de motorkap" gebeurt, en ik vind de Google documentatie onoverzichtelijk en onvolledig (en dan heb ik nog niet eens naar de -vaak brakke- Nederlandse vertalingen gekeken).
28-02-2024, 22:48 door Anoniem
Volgens je/de stelling wordt de te verwachten veiligheid van het account door de zwakste schakel bepaald.

Bij microsoft outlook account blijkt (althans zo'n jaar geleden) dat het (mij) niet lukt om alléén 2 yubikeys als inlog methode te configureren. Volgens de gedachte dat je altijd een backupinlog(methode) behoort te hebben was niet te vermijden dat zg. recovery of sms, authenticator of andere account moest zijn. Het is met niet gelukt om inlog(methode) te beperken tot 2 yubikeys (eentje bedoeld als backup/recovery). Ergo: de zwakste schakel was/is minder dan passkey (tpm of losse (yubi)key).
Voor mij was/is voor microsoft outlook dan ook nutteloos om een "zware" voordeur te installeren terwijl verlangd wordt een zwakkere achterdeur te hebben.
Het (b)lijkt dat proton email wel alleen yubikeys kan accepteren.

Het zou me niet verbazen als (veel) meer websites, naast het bieden van passkeys, afdwingen om een zwakkere recovery (zwakste schakel) te hebben.
Reageren
Ondersteunde bbcodes
Bold: [b]bold text[/b]
Italic: [i]italic text[/i]
Underline: [u]underlined text[/u]
Quote: [quote]quoted text[/quote]
URL: [url]https://www.security.nl[/url]
Config: [config]config text[/config]
Code: [code]code text[/code]

Je bent niet en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.