Computerbeveiliging
- Hoe je bad guys buiten de deur houdt
Passkeys voor leken
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.
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 (22)
06-06-2023, 22:32 door
Anoniem
Erik,
Wederom bedankt, weer wat geleerd!
Thanks!
Wederom bedankt, weer wat geleerd!
Thanks!
07-06-2023, 07:49 door
Anoniem
Dank je wel Erik.
Mooi leesbaar en begrijpelijk.
Noob
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?
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
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 !!!!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
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.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
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.
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:
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.
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).
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
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
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.
(sorry dubbel)
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.[...]
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).
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.
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.Nee, maar Windows Hello lijkt mij niet ontworpen 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:
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.Door Erik van Straten: WAT ZIJN PASSKEYS?
[...]
5) U mag er zelf niet meer bij
Dit lijkt me sterk.[...]
5) U mag er zelf niet meer bij
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,,,,
passkeys-demo.appspot.com,,,,
passkeys-demo.appspot.com,,,,
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):
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.
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
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.This won't clear any data from your devices.
This will also remove your sync passphrase. You can create a new passphrase.
[CLEAR DATA]
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.
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, 15:05 door
Erik van Straten
Update: Don't use Android passkeys!
Zie https://www.security.nl/posting/831554/Don%27t+use+Android+passkeys%21
Zie https://www.security.nl/posting/831554/Don%27t+use+Android+passkeys%21
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.
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.
15-04-2024, 12:52 door
Erik van Straten
Door Anoniem: Het zou me niet verbazen als (veel) meer websites, naast het bieden van passkeys, afdwingen om een zwakkere recovery (zwakste schakel) te hebben.
Sorry voor de late reactie, ik zie jouw post nu pas.Inderdaad, vooral als je Passkeys zo makkelijk kwijt kunt raken (zonder expliciete waarschuwing daarvoor) als onder Android, en organisaties geen "helpdesk" hebben die je kunt bellen en kunt (überhaupt zou kunnen?) bewijzen dat jij de rechtmatige accounteigenaar bent na account-lockout, zal er een alternatief 'zelfredmiddel" moeten bestaan - dat, in alle gevallen die ik ken, zwakker is dan Passkeys.
Dus inderdaad een voordeur met een beresterk slot, maar een achterdeur die iedereen met een ijzerdraadje open krijgt, zodat je toch naar binnen kunt als je jouw enige (niet te kopiëren = "backuppen") voordeursleutel kwijtraakt.
15-04-2024, 16:15 door
Erik van Straten
In https://www.heise.de/news/Google-Titan-Sicherheitsschluessel-Keine-Passkey-Verwaltung-9684858.html schrijven Dirk Knop en Ronald Eikenberg dat je op Google's "Titan" FIDO2 hardware sleutel welliswaar maximaal 250 WebAuthn "Passkeys" kunt opslaan (veel meer dan een Yubikey), maar dat je niet langer gebruikte "passkeys" daarop niet kunt verwijderen. Vol is dus vol.
Aan de andere kant is 250 nog steeds erg veel als je kijkt naar het aantal websites dat WebAuthn ondersteunt. En met potentieel zóveel "Passkeys" in één SPOF (Single Point Of Failure), waar je geen backups van kunt maken, wordt het defect raken of verliezen van zo'n hardware sleutel, mogelijk "een dingetje" (tenzij je op minstens één andere "schaduwsleutel", voor elk account, een alternatieve "Passkey" hebt opgeslagen).
Fabrikant Feitian zou gezegd hebben dat een fix hiervoor technisch onmogelijk is.
Er zouden ook problemen hebben bestaan bij het gebruik van deze Google Titan hardware key om in te loggen gebruikmakend van Microsoft's EntraID (https://www.reddit.com/r/Passkeys/comments/18lposx/google_titan_k52t_does_not_currently_work_on/), maar die problemen zouden ondertussen zijn opgelost.
Ten slotte meldt Heise ook:
Nb. ik zet "Passkeys" hier steeds tussen dubbele aanhalingstekens, omdat het geen echte Passkeys zijn, maar FIDO2 of WebAuthn credentials (ze zijn qua authenticatie-techniek vergelijkbaar met Passkeys, maar de essentie van Passkeys is dat zij in de cloud kunnen worden gebackupped (welliswaar zonder dat je daar zelf bij kunt) en via die cloud naar één of meer andere apparaten kunnen worden gesynchroniseerd (indien alles goed gaat).
Zijn er bezoekers van security.nl met ervaringen met Google Titan (en/of Feitian) FIDO2 hardware keys, en hoe zijn die ervaringen?
Aan de andere kant is 250 nog steeds erg veel als je kijkt naar het aantal websites dat WebAuthn ondersteunt. En met potentieel zóveel "Passkeys" in één SPOF (Single Point Of Failure), waar je geen backups van kunt maken, wordt het defect raken of verliezen van zo'n hardware sleutel, mogelijk "een dingetje" (tenzij je op minstens één andere "schaduwsleutel", voor elk account, een alternatieve "Passkey" hebt opgeslagen).
Fabrikant Feitian zou gezegd hebben dat een fix hiervoor technisch onmogelijk is.
Er zouden ook problemen hebben bestaan bij het gebruik van deze Google Titan hardware key om in te loggen gebruikmakend van Microsoft's EntraID (https://www.reddit.com/r/Passkeys/comments/18lposx/google_titan_k52t_does_not_currently_work_on/), maar die problemen zouden ondertussen zijn opgelost.
Ten slotte meldt Heise ook:
Die auf dem Stick abgelegten Passkeys lassen sich dadurch weder auflisten, noch können sie gelöscht werden.
Dat je niet zou kunnen zien voor welke accounts er "Passkeys" op zo'n Titan hardware key zouden staan, lijkt mij onacceptabel - vooral bij grote aantallen (zoals 250).Nb. ik zet "Passkeys" hier steeds tussen dubbele aanhalingstekens, omdat het geen echte Passkeys zijn, maar FIDO2 of WebAuthn credentials (ze zijn qua authenticatie-techniek vergelijkbaar met Passkeys, maar de essentie van Passkeys is dat zij in de cloud kunnen worden gebackupped (welliswaar zonder dat je daar zelf bij kunt) en via die cloud naar één of meer andere apparaten kunnen worden gesynchroniseerd (indien alles goed gaat).
Zijn er bezoekers van security.nl met ervaringen met Google Titan (en/of Feitian) FIDO2 hardware keys, en hoe zijn die ervaringen?
17-04-2024, 11:57 door
Anoniem
#1 te vergelijken met een ijzersterk (zeer lang, random - dus niet te raden, en wereldwijd uniek) wachtwoord.
Onjuist het is een challenge/response systeem welke password-sniffers, keylogging en MITM elimineerd.#2 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).
Onjuist, dan zou ik voor Google al oneindig veel domeinen moeten hebben.En ik wed dat als dit er niet was, dat je zou klagen dat het er niet was.
#4 https vereist en domeinnaam MOET kloppen
Ik gebruik passkeys op SSH op IP.Dat doe ik geheel in koele bloede, en dus zonder HTTPS en zonder domeinnaam.
#5 U mag er zelf niet meer bij
Compleet onzin. Probeer eens Nitrokey en Solokeys.Tenzij je verwachting is dat die jou tot root SSL CA zullen kronen. Blijf realistisch.
#6 Veel werkt nog niet
Hetgeen eeuwig zo zal blijven.Net als HTML5 nooit 100% zonder bugs zal zijn in 100% van alle huidige en 100% toekomstige browers, en gegarandeerd 100% compatible met HTML6. Blijf realistisch.
Plus je praat inmiddels over implementie i.p.v. het concept. Hetgeen niet in een vingerknip gefixed is.
Maar ondertussen werkt het best aardig, en is het vooruitzicht nog beter.
Of duidelijker gesteld:
wanneer implementatie te wensen over laat, betekend dat niet inherent dat het concept ruk was.
#13 Vendor lock-in
Tja, het is natuurlijk europees grondwettelijk bepaald dat je verplicht ben om slechts 1 passkey te mogen bezitten.Ja, inderdaad vendor-locks zullen vast wel her en der bestaan - al ben ik die zelf nog niet tegengekomen.
Een FIDO key is volgens mij gewoon een FIDO key.
Maar ga nu niet roepen dat passkeys de baby en het badwater achterna kunnen, enkel omdat 1 uit 100 fabrikanten een commerciele add-on aanbied.
#15 NIET VOOR LEKEN
Ha, inderdaad, dat is correct: het is juist TEGEN leken!Zodat iedere organisatie waar mensen werken die niet-zo-klassiek geschoold zich alsnog nuttig kunnen maken.
Zeer waardevolle bijdrage Erik, dank voor de heldere uitleg!
Behalve dat je zo onbegrijpelijk zuur doet: vooral niet de voordelen meeweegt, en daardoor op een absurd eindoordeel komt.Plus, waarom is jouw alternatief (?) beter voor een grote organisatie die werkelijke process-stagnatie problemen moet elimineren. Die wil van A naar B. Wanneer dat via C kan, ga je dat zeker niet via Z doen.
Tenzij via P of via K significante voordelen heeft om meteen 4 problemen grondig -i.p.v. 1 half- aan te pakken.
passkeys zijn hooguit handig op persoonlijke apparaten.
Onzin. De U in USB is niet meer universeel?Don't use Android passkeys!
Samengevat: "Ik kan mijn huis niet meer in omdat ik mijn sleutel kwijt ben, dus mensen: gebruik geen sleutels."Ik dacht dat je daar helemaal klaar mee was?
Als je een oneindige stroom onzin blaat (dingen uit het juiste verband rukt of geheel contextloos laat), dat herhaald totdat niemand meer reageert, dan heb je vroeg of laat jouw goddelijke gelijk.
Tot die tijd blijf ik onzin onzin noemen. Met argumentatie.
En wèl met RUIME praktijkervaring - aan beide kanten van het verhaal.
En daardoor zul je met betere argumenten moeten komen.
Biometrie
Hier valt veel over te zeggen maar deze posting is alweer erg lang. Wellicht kom ik hier in een andere bijdrage op terug.
Ja, dat die EXTRA factor vast ook nooit 100% veilig zal worden, maar ondertussen in de praktijk best wel een moeizaam en lastig obstakel vormt.Hier valt veel over te zeggen maar deze posting is alweer erg lang. Wellicht kom ik hier in een andere bijdrage op terug.
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".
Ah ja, dus omdat dat bij "Windows Hello" zo, is dat overal zo.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".
Whataboutism. En het tegendeel is echter waar.
Zoals die ene bank-reader welke door de ganse afdeling finance gebruikt wordt, kun je ervoor kiezen een key te delen.
Zijn er bezoekers van security.nl met ervaringen met Google Titan (en/of Feitian) FIDO2 hardware keys, en hoe zijn die ervaringen?
De voorloper ervan, de blauwe YubiKey, die speciaal voor Google gemaakt was.Ronduit teleurstellend:
nu log je in met email/passkey i.p.v. usr/pwd/key zoals elders wel kan - of in mijn geval usr/pwd/key/bio.
In mijn optiek is nu de gele post-it een blauw of wit stukje plastic geworden, en dat i.c.m. #2 (doch zonder biometrie) lijkt mij dan niet echt een verbetering.
Maar de Titan is niet exclusief. Dus mijn Kensington mag ook. Daardoor heb ik nu email/passkey/biometrie. Hetgeen ik toch wel beter acht dan een aloude usr/pwd (al dan niet met SMS op de telefoon die nog thuis ligt).
17-04-2024, 15:35 door
Erik van Straten
Door Anoniem:
a) Onjuist want "kunt u vergelijken met" - voor leken - is niet hetzelfde als claimen dat het feitelijke mechanisme daaronder identiek is (dat doe ik niet). Een HUGE probleem is echter dat, onmiddellijk na het inloggen met jouw Passkey, er een PRIMA met een wachtwoord te vergelijken (welliswaar vaak met beperkte geldigheidsduur - of onbeperkt, zoals standaard op tweakers.net), "shared secret" als authenticator wordt gebruikt bij elke https transactie. Het sniffen daarvan volstaat in elk geval om jouw sessie te kapen, en mogelijk om de authenticatie-instellingen van jouw account te wijzigen (met enige social engineering zal dat, in veel gevallen, gegarandeerd lukken).Door Erik van Straten op 06-06-2023:
1) Soort wachtwoord
Een passkey kunt u vergelijken met een ijzersterk (zeer lang, random - dus niet te raden, en wereldwijd uniek) wachtwoord.
Onjuist het is een challenge/response systeem welke password-sniffers, keylogging en MITM elimineerd.1) Soort wachtwoord
Een passkey kunt u vergelijken met een ijzersterk (zeer lang, random - dus niet te raden, en wereldwijd uniek) wachtwoord.
b) Onjuist het elimineerd [sic] geen password-sniffers en/of keyloggers die jouw "ontgendelcode" sniffen zodra je die, in plaats van middels biometrie, moet gebruiken om jouw passkey-manager te ontgrendelen.
c) Onjuist het elimineerd [sic] geen MITM via foute software op jouw toestel, niet op een website met een onterecht uitgegeven certificaat, niet op een website met foute beheerders, niet op een CDN-site (zoals bij Fastly), niet op een gehackte website, niet op een website die jouw browser Javascript laat ophalen van een vertrouwde third-party site - die gehacked is of foute beheerders heeft, en niet op een third-party site zoals mail.odido.com (die niet van Odido is).
Ik reageer niet verder op jouw gemanipuleerde quotes en onzin-antwoorden. Tip: drink voortaan goede wijn in plaats van schoonmaakazijn, dat maakt tevens het legen van jouw blaas minder pijnlijk.
18-04-2024, 14:24 door
Anoniem
Door Erik van Straten: Onjuist want "kunt u vergelijken met" - voor leken - is niet hetzelfde als claimen dat het feitelijke mechanisme daaronder identiek is (dat doe ik niet).
Goh, inderdaad, nu je het zegt... da's logica: verschillende dingen kun je niet vergelijken want dat zijn appels met peren, en dingen die hetzelfde zijn kun je niet vergelijken ze zijn immers hetzelfde.Doch... zelfs een digitale leek zal "challenges/response" best begrijpen, plus dat dat sterker is dan "static credentials". Hetgeen toch wel erg andere dingen zijn, en daarmee dus een slechte vergelijking was, die een objectief verhaal geen eer aandoet.
Temeer daar het tegenargument nogal mist; challenge/response valt niet te pre-genereren - zoals OTP's dat wel zijn.
Door Erik van Straten: elimineerd geen password-sniffers en/of keyloggers die jouw "ontgendelcode" sniffen zodra je die, in plaats van middels biometrie, moet gebruiken om jouw passkey-manager te ontgrendelen.
Waarmee een attacker nog altijd niet het werkelijke secret in handen heeft.Maar zelfs als er in de toekomst -of zelfs nu al- rotte appels tussen de peren blijken te zitten...
zagen wij in het verleden niet dat bijv. de SecurID tokenizer van RSA Security gewoon gebruikt bleef worden door menig instelling? Zoals de Tweede Kamer, en de Nederlandsche Bank en zelfs het Pentagon. Gewoon omdat ondanks dat falen die additionele factor nog altijd een lastig obstakel vormt.
Door Erik van Straten: MITM
Voorheen noemde je ook nog wel BGP hijacks. In no time gaan we het dan hebben over RPKI en misschien ook nog wel over DNSSEC met DANE als extra rookgordijn. Nogal omslachtige wijze om al die problemen aan te dragen als argument waarom de authenticatie-procedure geen verbetering is."security keys gaan geen Digicert 2 Debacle voorkomen - dus moeten we niet willen."
Dat argument noem je (hier niet letterlijk, doch indirect toch wel), en jouw monolitische conclusie is waanzin.
Door Erik van Straten:mail.odido.com (die niet van Odido is).
Van een multinational wiens naam vanuit het latijn vertaald naar "ik haat jou" moest je maar dito verwachtingen koesteren.Door Erik van Straten: Ik reageer niet verder op jouw gemanipuleerde quotes en onzin-antwoorden.
Amusant, zo'n uitspraak van een meester in manipulerende quotes, whataboutism, woorden in de mond leggen, en huilen over vergelijkingen waarmee je nota bene zelf begon te strooien (in "Gebruik geen Android passkeys").Jammer dat je mijn vraag om jouw betere alternatief -wederom- onbeantwoord laat.
Hadden we eenvoudig over alle argumentatie heen kunnen stappen, en wellicht de hand kunnen schudden.
Maar die oorverdovende stilte kwam niet geheel onverwacht.
Door Erik van Straten: Tip: drink voortaan goede wijn in plaats van schoonmaakazijn, dat maakt tevens het legen van jouw blaas minder pijnlijk.
Zelfs je poging tot komische humor is -wederom- exact het tegengesteld aan de realiteit:schoonmaakazijn is juist het allerbeste middel tegen verkalking.
Verkalking is trouwens niet enkel een probleem voor de door jouw genoemde blaas, maar heeft ook ernstige gevolgen voor spieren en pezen. Maar dat terzijde, want lijkt mij nogal irrelevant voor het onderwerp.
18-04-2024, 15:50 door
Erik van Straten
Door Anoniem: Jammer dat je mijn vraag om jouw betere alternatief -wederom- onbeantwoord laat.
07-06-2023, 15:11 door Erik van Straten - Bijgewerkt: 07-06-2023, 15:37: [...]
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).
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).
Uit https://security.nl/posting/838325:
Beste mensen: gebruik een wachtwoordmanager die de login-gegevens voor een website alleen vrijgeeft als de domeinnaam van de website klopt!
Kopie van https://security.nl/posting/838328:
Vandaag, 09:43 door Erik van Straten - Bijgewerkt: Vandaag, 10:43: Zojuist ben ik ingelogd op security.nl vanaf mijn Android smartphone, als volgt:
1) Ik opende https://security.nl in Firefox (voor Android). Die link had in een phishingmail kunnen staan, en bijvoorbeeld https://securlty.nl kunnen luiden. Sterker, precies zoals Vitens doet [1]: de tekst "boven de link" in de mail had security.nl kunnen luiden, met "daaronder" genoemde link met de iets afwijkende domeinnaam.
Nb. Onder Android heb je geen browser plug-ins/add-ons nodig om bijv. KeePassDX te kunnen gebruiken. Die wachtwoordmanager werkt automatisch in elke webbrowser die ik gebruik (Chrome, Firefox Nightly en Firefox Focus).
2) Ik drukte rechtsboven op "Inloggen" waarna een inlog-dialoogbox (een pop-up venster met invulvelden) verschijnt.
3) Als ik in het wachtwoordveld druk, verschijnt een klein pop-up venstertje (met de groene kleur van KeePassDX) met bovenin "www.security.nl" en daaronder een "knop" met de tekst "Sign in with KeePassDX". Uit die eerste tekst blijkt dat Android al heeft herkend om welke website, d.w.z. om welke domeinnaam, het gaat, en dat reeds heeft doorgegeven aan KeePassDX.
4) Ik druk op de 'knop" met de tekst "Sign in with KeePassDX".
5) Vervolgens moet ik, in een geheel ander scherm (van KeePassDX, full screen), een wachtwoorddatabase kiezen (zelf heb ik er twee, waarvan ééntje voor tests). Ik kies de gewenste.
6) Er verschijnt het verzoek om de (versleutelde) wachtwoorddatabase te ontgrendelen - met mijn vingerafdruk (effectief is de wachtwoorddatabase versleuteld met een lang wachtwoord, dat -effectief- veilig in hardware van mijn Android smartphone is opgeslagen). Met mijn vingerafdruk geeft Android dat lange wachtwoord vrij, waarmee de database wordt intgrendeld). Ik leg mijn vinger op de vingerafdrukscanner, met succes.
7) Vanuit het andere scherm ben ik weer terug in de browser met de inlog-dialoogbox van security.nl. Daaronder verschijnt nu een keuzescherm, ik kan kiezen om in te loggen als:
• Onbekend (test) (Onbekend (test))
• Erik van Straten @ security.nl (E<geheim>@xs4all.nl)
Die bovenste regel heb ik voor tests gebruikt, maar had ook een echt tweede account kunnen zijn. Nb. je ziet achtereenvolgens de accountnaam op de site, en het gebruikte user-ID, meestal jouw e-mailadres.
8) Ik druk op de onderste regel: dan vult KeePasdDX automatisch beide velden in, en maakt (ter verduidelijking) de achtergrond van die velden geel.
9) Als ik nu op de knop "Inloggen" druk, ben ik ingelogd op security.nl.
Klinkt moeilijk, is dat niet: met een paar keer drukken en een vingerafdruk ben ik ingelogd op de juiste website.
Dat moet een rode vlag zijn!
De domeinnaam is namelijk onbekend in de wachtwoordmanagerdatabase, de kans is maximaal dat je op een nepsite probeert in te loggen. Dat is het moment om te stoppen!
[1] https://www.security.nl/posting/837529/Vitens%3A+AVG%3F+Lets+phish%21
1) Ik opende https://security.nl in Firefox (voor Android). Die link had in een phishingmail kunnen staan, en bijvoorbeeld https://securlty.nl kunnen luiden. Sterker, precies zoals Vitens doet [1]: de tekst "boven de link" in de mail had security.nl kunnen luiden, met "daaronder" genoemde link met de iets afwijkende domeinnaam.
Nb. Onder Android heb je geen browser plug-ins/add-ons nodig om bijv. KeePassDX te kunnen gebruiken. Die wachtwoordmanager werkt automatisch in elke webbrowser die ik gebruik (Chrome, Firefox Nightly en Firefox Focus).
2) Ik drukte rechtsboven op "Inloggen" waarna een inlog-dialoogbox (een pop-up venster met invulvelden) verschijnt.
3) Als ik in het wachtwoordveld druk, verschijnt een klein pop-up venstertje (met de groene kleur van KeePassDX) met bovenin "www.security.nl" en daaronder een "knop" met de tekst "Sign in with KeePassDX". Uit die eerste tekst blijkt dat Android al heeft herkend om welke website, d.w.z. om welke domeinnaam, het gaat, en dat reeds heeft doorgegeven aan KeePassDX.
4) Ik druk op de 'knop" met de tekst "Sign in with KeePassDX".
5) Vervolgens moet ik, in een geheel ander scherm (van KeePassDX, full screen), een wachtwoorddatabase kiezen (zelf heb ik er twee, waarvan ééntje voor tests). Ik kies de gewenste.
6) Er verschijnt het verzoek om de (versleutelde) wachtwoorddatabase te ontgrendelen - met mijn vingerafdruk (effectief is de wachtwoorddatabase versleuteld met een lang wachtwoord, dat -effectief- veilig in hardware van mijn Android smartphone is opgeslagen). Met mijn vingerafdruk geeft Android dat lange wachtwoord vrij, waarmee de database wordt intgrendeld). Ik leg mijn vinger op de vingerafdrukscanner, met succes.
7) Vanuit het andere scherm ben ik weer terug in de browser met de inlog-dialoogbox van security.nl. Daaronder verschijnt nu een keuzescherm, ik kan kiezen om in te loggen als:
• Onbekend (test) (Onbekend (test))
• Erik van Straten @ security.nl (E<geheim>@xs4all.nl)
Die bovenste regel heb ik voor tests gebruikt, maar had ook een echt tweede account kunnen zijn. Nb. je ziet achtereenvolgens de accountnaam op de site, en het gebruikte user-ID, meestal jouw e-mailadres.
8) Ik druk op de onderste regel: dan vult KeePasdDX automatisch beide velden in, en maakt (ter verduidelijking) de achtergrond van die velden geel.
9) Als ik nu op de knop "Inloggen" druk, ben ik ingelogd op security.nl.
Klinkt moeilijk, is dat niet: met een paar keer drukken en een vingerafdruk ben ik ingelogd op de juiste website.
Herkennen van nepsites
Als ik op een site, waarop ik géén account heb, op zo'n wachtwoordveld druk, verschijnt ook een popup van KeePassDX, ook met vermelding van de domeinnaam. Als ik dezelfde procedure volg in KeePassDX, moet ik echter gaan zoeken in de database naar "passende inloggegevens".Dat moet een rode vlag zijn!
De domeinnaam is namelijk onbekend in de wachtwoordmanagerdatabase, de kans is maximaal dat je op een nepsite probeert in te loggen. Dat is het moment om te stoppen!
[1] https://www.security.nl/posting/837529/Vitens%3A+AVG%3F+Lets+phish%21
Dit werkt overigens vergelijkbaar en prima met KeePassium onder iOS en iPadOS.
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 ingelogd 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.
Digital Designer
Ben jij een Grafisch vormgever, UI-designer, Game-artist of gewoon een ‘self-proclaimed creative genius’, die op zoek is naar een leuke en uitdagende baan waarin je al je creativiteit kwijt kan?Je werkt samen met onze developers en UI/UX-designer aan onze Gamified Cybersecurity Challenges welke jij voorziet van de mooiste designs.
Cyber Security Trainer
"You know that feeling after you have been to the cinema and seen an exciting movie? It's the same after this training. I can only say that this is probably the BEST TRAINING that I've ever done!!!”
Are you ready for a challenge?
Senior Full Stack Developer
Als full stack developer bij Certified Secure maak je de mooiste cybersecurity challenges die onze deelnemers wereldwijd uitdagen en inspireren. Alle challenges zijn gebaseerd op actuele kwetsbaarheden, je komt dus telkens nieuwe technieken tegen, van machine learning tot web assembly, van Swift UI tot GCP.