Security Professionals
- ipfw add deny all from eindgebruikers to any
Passkeys PQC snake oil
19-08-2023, 12:23 door Erik van Straten, 3 reacties
TL:DR;
Google marketing probeert passkeys (en FIDO2 hardware keys) sterker te laten lijken dan zij zijn door er PQC (Post Quantum Cryptography) voor aan te kondigen [1] (overgenomen door "de pers" in o.a. [2] en [3]). Dit is larie omdat:
a) Direct daarna onversleutelde session cookies (of andere gebruiker-authenticatietokens) én meestal noodzakelijkerwijs authentieke en soms vertrouwelijke informatie over dezelfde "lijn" gaan, d.w.z. een versleutelde verbinding met een hopelijk op betrouwbare wijze geauthenticeerde server;
b) De public key van een passkey slechts éénmalig zelf over die "lijn" gaat (tijdens het registreren, niet bij inloggen).
Noodzaak PQC
Omdat we niet weten wanneer zal blijken dat een land of organisatie een quantum computer heeft waarmee het het Diffie-Hellman algoritme en/of andere vormen van momenteel gebruikte asymmetrische cryptografie live kan kraken, en/of uit eerder opgeslagen versleutelde sessies vertrouwelijke informatie kan achterhalen, hebben we ASAP behoefte aan PQC. Maar niet in de eerste plaats voor WebAuthn (Passkeys en FIDO2 hardware keys).
Voordelen WebAuthn t.o.v. wachtwoorden
Zoals ik in https://security.nl/posting/798699/Passkeys+voor+leken schreef (iets ingekort en typo gefixed):
Authenticeren en versleutelen
Voorwaarde voor het uitwisselen van authentieke en mogelijk vertrouwelijke informatie -na inloggen- is een versleutelde verbinding tussen wederzijds geauthenticeerde endpoints. Dat begint met authenticatie van de server en het versleutelen van de verbinding, pas daarná wordt, door de server, de gebruiker (of een proces) op de client geauthenticeerd.
Omdat de server is geauthenticeerd (door de client) en de verbinding is versleuteld op het moment dat een passkey wordt gebruikt (om in te loggen, d.w.z. de client te authenticeren), boeit het niet of er een plain-text wachtwoord of een onkraakbare signature van onder andere een nonce over de (versleutelde) lijn gaat: die informatie hoort sowieso ontoegankelijk te zijn voor aanvallers, want zij horen geen toegang te hebben tot onversleutelde informatie op die lijn. Want even later gaan er -eveneens plain-text- session cookies of andere tokens over diezelfde lijn, in combinatie met de daadwerkelijke informatie waar het feitelijk om draait.
Niet 100% phishing-proof
Of "iets" phishing-proof is, hangt af van de definitie van phishing. Vaak wordt met phishing bedoeld het ontfutselen van inloggegevens via een website met een afwijkende domeinnaam, maar linksom of rechtsom wil je niet dat een kwaadwillende toegang krijgt tot jouw account(s) (ongeacht hoe dat heet).
Op z'n minst in de volgende situaties (gedocumenteerd of denkbaar) voorkómt WebAuthn niet dat een kwaadwillende toegang krijgt tot jouw account:
1) Bij een onterecht uitgegeven https servercertificaat tijdens een BGP-hijack [4].
2) Bij een onterecht uitgegeven https servercertificaat tijdens een DNS-aanval [5] die zowel de certificaatuitgever als client(s) treft.
3) Nadat een kwaadwillende schrijftoegang tot DNS-records van het inlogdomein heeft verkregen. Hierbij zijn twee soorten aanvallen denkbaar:
3.a) De aanvaller laat het DNS-record van de inlogserver wijzen naar diens eigen server, en zet, als AitM (Attacker in the Middle), inlogverzoeken door naar de echte server. Nb. zo'n aanval wordt meestal snel opgemerkt.
3.b) Domain Shadowing [6]: de aanvaller maakt een subdomein aan zoals newlogon.example.com en mailt slachtoffers dat zij voortaan op newlogon.example.com moeten inloggen. Als ik WebAuthn goed begrijp werkt deze aanval uitsluitend als de echte inlogserver, tijdens inloggen, niet vaststelt dat newlogon.example.com géén toegestane inlogserver is.
4) Bij een aanval via een "CNAME server" (gehacked of foute medewerker), zoals mailings.example.com. Net als bij 3.b kan dit alleen als de echte inlogserver, tijdens inloggen, niet vaststelt dat mailings.example.com géén toegestane inlogserver is. Met "CNAME server" bedoel ik de server van een derde partij die bijvoorbeeld de verzending van bulk-email voor haar rekening neemt.
5) Indien een https servercertificaat wordt uitgegeven door een onbetrouwbare partij waarvan de client een rootcertificaat heeft geïnstalleerd (dan is tevens een netwerk- of DNS-aanval op de client nodig). Denk aan een private key die op straat ligt, horend bij een rootcertificaat dat één of meer clients geïnstalleerd hebben: [7] (Fortinet spullen blijken overigens eindeloos lek, zie [8]) en [9] (Kazachstan lijkt https-AitM te hebben opgegeven, maar oproepen voor interceptie, waaronder Client Side Scanning [10] -effectief client compromise, zie ook punt 11- blijven terugkeren).
6) Indien "meekijkende" third party servers (zoals Google Analytics en consorten) kwaadaardig blijken. Ook als zij geen Javascript kunnen injecteren op de sessie met de inlogserver, kunnen zij mogelijk, ná inloggen, wel kwaadaardige Javascript injecteren die een backdoor op jouw account aanmaakt (sowieso kunnen ze alles zien, én wijzigen, wat jij te zien krijgt en/of naar de bedoelde server stuurt).
7) Indien een aanvaller op alternatieve wijze kan inloggen op jouw account (dit is, voorlopig, een zeer groot risico, waarbij phishing-mails/SMSjes etc. een grote rol kunnen spelen).
8) Indien je jouw passkey (voor het eerst) registreert op een nepserver.
9) Indien de gebruiker zich laat misleiden met een BitB (Browser in the Browser) aanval (zie bijv. [11] en [12]).
10) Indien de server gecompromitteerd is (geweest, er kunnen bijv. passkeys van kwaadwillenden aan accounts zijn toegevoegd; zo'n public key zit niet in een certificaat waarin staat van wie die public key is).
11) Indien de client gecompromitteerd is (geweest), zie bijv. [13] en [14] (Visual Studio extensions die toegang hebben tot jouw "key chain"; private keys van passkeys zouden gekopiejat kunnen zijn).
Kinderziektes
Laat Google eerst de m.i. ernstige passkey bug fixen die ik meer dan 60 dagen geleden aan hen heb gemeld, in plaats van te proberen te imponeren met irrelevant nieuws (ook bij Apple heb ik al meer dan 2 maanden een bugreport uit staan voor een ernstige kwetsbaarheid - ook daar blijft het oorverdovend stil).
Echt PQC nieuws
In [15] lees ik dat Google serieus bezig is met PQC voor het web, maar dat lijkt "de pers" minder belangrijk te vinden dan irrelevant nieuws over passkeys.
Wél groot passkey-nieuws zou ik het vinden als bijvoorbeeld Google een mechanisme zou bedenken en realiseren waarmee iemand, bijvoorbeeld nadat diens smartphone is gestolen, in één keer alle passkeys (private keys) op diens toestel zou kunnen "intrekken" om misbruik van die passkeys te voorkómen.
Wellicht is het toch een goed idee om, bij een volgende generatie passkeys, de public keys daarvan in (revocable) certificaten op te nemen?
Referenties
[1] https://security.googleblog.com/2023/08/toward-quantum-resilient-security-keys.html
[2] https://www.bleepingcomputer.com/news/security/google-released-first-quantum-resilient-fido2-key-implementation/
[3] https://arstechnica.com/security/2023/08/passkeys-are-great-but-not-safe-from-quantum-computers-dilithium-could-change-that/
[4] https://arstechnica.com/information-technology/2022/09/how-3-hours-of-inaction-from-amazon-cost-cryptocurrency-holders-235000/
[5] https://www.bleepingcomputer.com/news/security/maginotdns-attacks-exploit-weak-checks-for-dns-cache-poisoning/
[6] https://unit42.paloaltonetworks.com/domain-shadowing/
[7] https://www.security.nl/posting/37180/Fortinet+SSL+DPI+ook+lek+%28net+als+Cyberoam%29%3F#posting322952
[8] (PDF) https://media.defcon.org/DEF%20CON%2031/DEF%20CON%2031%20presentations/Tom%20Pohl%20-%20Private%20Keys%20in%20Public%20Places.pdf
[9] https://www.security.nl/posting/734882/EFF%3A+voorstel+Europese+digitale+identiteit+bedreigt+https-beveiliging+browsers
[10] https://www.security.nl/posting/798124/Organisaties+starten+petitie+voor+invoering+van+scanplan+Europese+Commissie#posting798159
[11] https://www.security.nl/posting/806754/Criminelen+verspreiden+ransomware+via+zogenaamde+TripAdvisor-klacht#posting806771
[12] https://www.bleepingcomputer.com/news/security/new-phishing-toolkit-lets-anyone-create-fake-chrome-browser-windows/
[13] https://www.security.nl/posting/806965/android_ios+teamviewer+bankfraud
[14] https://cycode.com/blog/exposing-vscode-secrets/
[15] https://www.theregister.com/2023/08/12/google_chrome_kem/
Google marketing probeert passkeys (en FIDO2 hardware keys) sterker te laten lijken dan zij zijn door er PQC (Post Quantum Cryptography) voor aan te kondigen [1] (overgenomen door "de pers" in o.a. [2] en [3]). Dit is larie omdat:
a) Direct daarna onversleutelde session cookies (of andere gebruiker-authenticatietokens) én meestal noodzakelijkerwijs authentieke en soms vertrouwelijke informatie over dezelfde "lijn" gaan, d.w.z. een versleutelde verbinding met een hopelijk op betrouwbare wijze geauthenticeerde server;
b) De public key van een passkey slechts éénmalig zelf over die "lijn" gaat (tijdens het registreren, niet bij inloggen).
Noodzaak PQC
Omdat we niet weten wanneer zal blijken dat een land of organisatie een quantum computer heeft waarmee het het Diffie-Hellman algoritme en/of andere vormen van momenteel gebruikte asymmetrische cryptografie live kan kraken, en/of uit eerder opgeslagen versleutelde sessies vertrouwelijke informatie kan achterhalen, hebben we ASAP behoefte aan PQC. Maar niet in de eerste plaats voor WebAuthn (Passkeys en FIDO2 hardware keys).
Voordelen WebAuthn t.o.v. wachtwoorden
Zoals ik in https://security.nl/posting/798699/Passkeys+voor+leken schreef (iets ingekort en typo gefixed):
Een passkey is een sterk authenticatiemiddel omdat, in de eerste plaats, software de domeinnaam checkt en in de tweede plaats, dat een de public key (op de server) effectief een ijzersterk wachtwoord is.
Een wachtwoordmanager die op basis van de domeinnaam (of volledige URL) een wachtwoord vrijgeeft, en die je lange unieke random wachtwoorden laat genereren, komt, qua veiligheid, zeer dicht in de buurt van passkeys (en kan op punten sterker zijn, zoals punt 3.b en 4 verderop). Bovendien is attestation dan niet "ingebouwd" (wat een voordeel en een nadeel voor gebruikers kan zijn).Authenticeren en versleutelen
Voorwaarde voor het uitwisselen van authentieke en mogelijk vertrouwelijke informatie -na inloggen- is een versleutelde verbinding tussen wederzijds geauthenticeerde endpoints. Dat begint met authenticatie van de server en het versleutelen van de verbinding, pas daarná wordt, door de server, de gebruiker (of een proces) op de client geauthenticeerd.
Omdat de server is geauthenticeerd (door de client) en de verbinding is versleuteld op het moment dat een passkey wordt gebruikt (om in te loggen, d.w.z. de client te authenticeren), boeit het niet of er een plain-text wachtwoord of een onkraakbare signature van onder andere een nonce over de (versleutelde) lijn gaat: die informatie hoort sowieso ontoegankelijk te zijn voor aanvallers, want zij horen geen toegang te hebben tot onversleutelde informatie op die lijn. Want even later gaan er -eveneens plain-text- session cookies of andere tokens over diezelfde lijn, in combinatie met de daadwerkelijke informatie waar het feitelijk om draait.
Niet 100% phishing-proof
Of "iets" phishing-proof is, hangt af van de definitie van phishing. Vaak wordt met phishing bedoeld het ontfutselen van inloggegevens via een website met een afwijkende domeinnaam, maar linksom of rechtsom wil je niet dat een kwaadwillende toegang krijgt tot jouw account(s) (ongeacht hoe dat heet).
Op z'n minst in de volgende situaties (gedocumenteerd of denkbaar) voorkómt WebAuthn niet dat een kwaadwillende toegang krijgt tot jouw account:
1) Bij een onterecht uitgegeven https servercertificaat tijdens een BGP-hijack [4].
2) Bij een onterecht uitgegeven https servercertificaat tijdens een DNS-aanval [5] die zowel de certificaatuitgever als client(s) treft.
3) Nadat een kwaadwillende schrijftoegang tot DNS-records van het inlogdomein heeft verkregen. Hierbij zijn twee soorten aanvallen denkbaar:
3.a) De aanvaller laat het DNS-record van de inlogserver wijzen naar diens eigen server, en zet, als AitM (Attacker in the Middle), inlogverzoeken door naar de echte server. Nb. zo'n aanval wordt meestal snel opgemerkt.
3.b) Domain Shadowing [6]: de aanvaller maakt een subdomein aan zoals newlogon.example.com en mailt slachtoffers dat zij voortaan op newlogon.example.com moeten inloggen. Als ik WebAuthn goed begrijp werkt deze aanval uitsluitend als de echte inlogserver, tijdens inloggen, niet vaststelt dat newlogon.example.com géén toegestane inlogserver is.
4) Bij een aanval via een "CNAME server" (gehacked of foute medewerker), zoals mailings.example.com. Net als bij 3.b kan dit alleen als de echte inlogserver, tijdens inloggen, niet vaststelt dat mailings.example.com géén toegestane inlogserver is. Met "CNAME server" bedoel ik de server van een derde partij die bijvoorbeeld de verzending van bulk-email voor haar rekening neemt.
5) Indien een https servercertificaat wordt uitgegeven door een onbetrouwbare partij waarvan de client een rootcertificaat heeft geïnstalleerd (dan is tevens een netwerk- of DNS-aanval op de client nodig). Denk aan een private key die op straat ligt, horend bij een rootcertificaat dat één of meer clients geïnstalleerd hebben: [7] (Fortinet spullen blijken overigens eindeloos lek, zie [8]) en [9] (Kazachstan lijkt https-AitM te hebben opgegeven, maar oproepen voor interceptie, waaronder Client Side Scanning [10] -effectief client compromise, zie ook punt 11- blijven terugkeren).
6) Indien "meekijkende" third party servers (zoals Google Analytics en consorten) kwaadaardig blijken. Ook als zij geen Javascript kunnen injecteren op de sessie met de inlogserver, kunnen zij mogelijk, ná inloggen, wel kwaadaardige Javascript injecteren die een backdoor op jouw account aanmaakt (sowieso kunnen ze alles zien, én wijzigen, wat jij te zien krijgt en/of naar de bedoelde server stuurt).
7) Indien een aanvaller op alternatieve wijze kan inloggen op jouw account (dit is, voorlopig, een zeer groot risico, waarbij phishing-mails/SMSjes etc. een grote rol kunnen spelen).
8) Indien je jouw passkey (voor het eerst) registreert op een nepserver.
9) Indien de gebruiker zich laat misleiden met een BitB (Browser in the Browser) aanval (zie bijv. [11] en [12]).
10) Indien de server gecompromitteerd is (geweest, er kunnen bijv. passkeys van kwaadwillenden aan accounts zijn toegevoegd; zo'n public key zit niet in een certificaat waarin staat van wie die public key is).
11) Indien de client gecompromitteerd is (geweest), zie bijv. [13] en [14] (Visual Studio extensions die toegang hebben tot jouw "key chain"; private keys van passkeys zouden gekopiejat kunnen zijn).
Kinderziektes
Laat Google eerst de m.i. ernstige passkey bug fixen die ik meer dan 60 dagen geleden aan hen heb gemeld, in plaats van te proberen te imponeren met irrelevant nieuws (ook bij Apple heb ik al meer dan 2 maanden een bugreport uit staan voor een ernstige kwetsbaarheid - ook daar blijft het oorverdovend stil).
Echt PQC nieuws
In [15] lees ik dat Google serieus bezig is met PQC voor het web, maar dat lijkt "de pers" minder belangrijk te vinden dan irrelevant nieuws over passkeys.
Wél groot passkey-nieuws zou ik het vinden als bijvoorbeeld Google een mechanisme zou bedenken en realiseren waarmee iemand, bijvoorbeeld nadat diens smartphone is gestolen, in één keer alle passkeys (private keys) op diens toestel zou kunnen "intrekken" om misbruik van die passkeys te voorkómen.
Wellicht is het toch een goed idee om, bij een volgende generatie passkeys, de public keys daarvan in (revocable) certificaten op te nemen?
Referenties
[1] https://security.googleblog.com/2023/08/toward-quantum-resilient-security-keys.html
[2] https://www.bleepingcomputer.com/news/security/google-released-first-quantum-resilient-fido2-key-implementation/
[3] https://arstechnica.com/security/2023/08/passkeys-are-great-but-not-safe-from-quantum-computers-dilithium-could-change-that/
[4] https://arstechnica.com/information-technology/2022/09/how-3-hours-of-inaction-from-amazon-cost-cryptocurrency-holders-235000/
[5] https://www.bleepingcomputer.com/news/security/maginotdns-attacks-exploit-weak-checks-for-dns-cache-poisoning/
[6] https://unit42.paloaltonetworks.com/domain-shadowing/
[7] https://www.security.nl/posting/37180/Fortinet+SSL+DPI+ook+lek+%28net+als+Cyberoam%29%3F#posting322952
[8] (PDF) https://media.defcon.org/DEF%20CON%2031/DEF%20CON%2031%20presentations/Tom%20Pohl%20-%20Private%20Keys%20in%20Public%20Places.pdf
[9] https://www.security.nl/posting/734882/EFF%3A+voorstel+Europese+digitale+identiteit+bedreigt+https-beveiliging+browsers
[10] https://www.security.nl/posting/798124/Organisaties+starten+petitie+voor+invoering+van+scanplan+Europese+Commissie#posting798159
[11] https://www.security.nl/posting/806754/Criminelen+verspreiden+ransomware+via+zogenaamde+TripAdvisor-klacht#posting806771
[12] https://www.bleepingcomputer.com/news/security/new-phishing-toolkit-lets-anyone-create-fake-chrome-browser-windows/
[13] https://www.security.nl/posting/806965/android_ios+teamviewer+bankfraud
[14] https://cycode.com/blog/exposing-vscode-secrets/
[15] https://www.theregister.com/2023/08/12/google_chrome_kem/
Reacties (3)
Signal gaat nu ook over op PQC
Verder bedankt voor je bijdragen hier Erik
Verder bedankt voor je bijdragen hier Erik
28-09-2023, 11:04 door
Erik van Straten
Door Anoniem: Signal gaat nu ook over op PQC
Prima, die "dubbele aanpak" lijkt mij ook verstandig bij TLS.Maar voor Passkeys is dit onzin, vooral als private keys (van Passkeys) "versleuteld" met een screen-lock PIN-code van slechrs 4 cijfers op servers van Google worden opgeslagen. Quantum computers lijken mij dan niet je grootste zorg (vooral niet vanwege wat ik bovenaan deze pagina schreef). Immers, een PINcode van 4 cijfers brute-forcen is een makkie als er geen account lockout mogelijk is (zoals bij een versleuteld bestand).
In elk geval op Android biedt Google aan om, in plaats van de standaard gekozen schermslotcode voor versleuteling van de private keys van Passkeys te gebruiken, zowel wachtwoorden als Passkey-private-keys te versleutelen met het wachtwoord voor jouw Google account "zodat Google er niet meer bij kan" {1}.
{1} Google noemt dat "on-device" encryption: https://support.google.com/accounts/answer/11350823:
With on-device encryption, no one besides you will be able to access your encrypted data.
Om vervolgens, als je in https://passwords.google.com details van die opgeslagen gegevens wilt bekijken, jou te vragen om het wachtwoord van jouw Google account in te voeren op hun server. Hoezo zou Google dan niet bij al jouw inloggegevens kunnen?
OK, waarschijnlijk zet die server jouw wachtwoord meteen om in een eenweg-afgeleide daarvan (en vergelijkt dat met de tijdens de laatste wachtwoord-wijziging opgeslagen eenweg-afgeleide) en wordt jouw wachtwoord zelf nooit bewaard, maar zeker weten doe je dat natuurlijk niet.
Een "sync passphrase" lijkt een veiliger optie, maar daarmee had ik, tijdens experimenten, een boel gedonder met het synchroniseren van Passkeys tussen twee Android smartphones (Passkeys synchroniseerden wel, maar op smartphone A aangemaakte Passkeys werkten niet op smartphone B en vice versa). Ook heb ik (nog) niet kunnen vaststellen dat private keys van Passkeys daadwerkelijk worden versleuteld met zo'n sync passphrase. Veel twijfels en kinderziektes nog dus.
Door Anoniem: Verder bedankt voor je bijdragen hier Erik
Graag gedaan! En dank voor jouw post: zoiets beanwoorden zet mij vaak aan tot nog eens overpijnzen en tot nieuwe inzichten.Door Anoniem: Signal gaat nu ook over op PQC
Signal voegt bescherming toe tegen dreiging van quantum computer
woensdag 20 september 2023, 09:51 door Redactie
https://www.security.nl/posting/810937/Signal+voegt+bescherming+toe+tegen+dreiging+van+quantum+computer
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
