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):
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/