Il 4 agosto 2026 i ricercatori di Unit 42 di Palo Alto Networks hanno pubblicato una ricerca che smonta la percezione di invulnerabilità delle passkey su Windows. Tre tecniche di attacco — Pass-ta-key, Silver Pass-ta-key e Golden Pass-ta-key — permettono a un malware già presente sulla macchina, con soli privilegi utente comune, di ottenere risposte di autenticazione valide per account protetti da passkey FIDO2. Il bersaglio è Google Password Manager in Chrome, il più grande ecosistema passkey al mondo. Il protocollo FIDO2 non è violato: la falla risiede nell'implementazione vendor-specifica di Google.
- Tre tecniche documentate — Pass-ta-key, Silver Pass-ta-key, Golden Pass-ta-key — aggirano le passkey in Chrome su Windows con TPM, senza richiedere privilegi elevati.
- Pass-ta-key sfrutta chiavi TPM senza nome persistito per firmare richieste con flag User Verified a zero; eBay ha accettato la risposta prima di correggere, GitHub l'ha respinta.
- Silver Pass-ta-key forza la ri-registrazione del dispositivo registrando una chiave di verifica controllata dall'attaccante, senza che il servizio verifichi provenienza da hardware sicuro.
- Golden Pass-ta-key estrae il Security Domain Secret di 32 byte dalla memoria di Chrome: un segreto master che protegge tutte le passkey sincronizzate, senza meccanismo di rotazione o revoca.
Come funziona il primo attacco: Pass-ta-key
Il malware recupera il file wrapped_identity_private_key dal percorso %LocalAppData%\Google\Chrome\User Data\Profilo\Sync Data\LevelDB, dove Chrome conserva i record delle credenziali sincronizzate. Con questa chiave avvolta, l'attaccante chiama l'API Windows NCryptCreatePersistedKey senza specificare un nome di persistenza, creando un handle crittografico temporaneo. La firma produce una risposta di autenticazione formalmente valida, con il flag User Verified impostato a zero.
Il controllo di questo flag divide i servizi. GitHub lo valida e ha respinto il tentativo dei ricercatori. eBay, al momento del test, non lo validava e ha accettato la risposta — poi ha corretto il comportamento. La discrepanza dimostra che la robustezza delle passkey dipende da implementazioni server-side disallineate, non solo dall'autenticatore client.
La seconda tecnica: forzare la ri-registrazione
Silver Pass-ta-key opera invalidando la chiave di verifica esistente o cancellando il file di stato locale del browser. Chrome interpreta l'evento come necessità di ri-registrare il dispositivo presso il cloud authenticator Google. Il malware intercetta questo flusso e registra una propria chiave di verifica. Il servizio remoto accetta la nuova chiave senza verificare che provenga da un hardware sicuro originale.
La conseguenza è sottile ma grave: l'utente non riceve alcun segnale d'allarme, la procedura appare legittima, e il dispositivo rimane funzionalmente sincronizzato. L'attaccante ha sostituito l'ancora di trust senza violare crittografia, ma abusando della gestione del ciclo di vita delle chiavi.
Il terzo anello: il Security Domain Secret in memoria
Golden Pass-ta-key colpisce il Security Domain Secret (SDS), un blocco di 32 byte che protegge tutte le passkey sincronizzate dell'account Google. Durante la registrazione o il recupero, il SDS transita in chiaro nella memoria del processo Chrome. I ricercatori hanno documentato che, forzando una ri-registrazione e analizzando il pattern di allocazione, è possibile estrarre il segreto direttamente dalla memoria utente.
"anche se Google ha rimosso questo segreto dall'output di logging di Chrome dopo la nostra segnalazione, il SDS viene comunque inviato al client e resta accessibile nella memoria di processo di Chrome. Se l'attaccante costringe la vittima a ri-registrarsi presso il cloud authenticator e sa quale schema cercare, può estrarlo direttamente dalla memoria" — Unit 42 di Palo Alto Networks (via Hardware Upgrade)
Il problema strutturale è che non esiste meccanismo per ruotare o revocare il Security Domain Secret. Una volta estratto, il valore compromette potenzialmente tutte le passkey sincronizzate passate e future. Come hanno sottolineato i ricercatori: "Nell'implementazione attuale non risulta un modo per ruotare o revocare il segreto, quindi anche le passkey sincronizzate in futuro resterebbero protette dallo stesso valore".
Chrome come weak link: architettura vs. protocollo
La ricerca separa nettamente protocollo e implementazione. FIDO2/WebAuthn presuppone che l'autenticatore locale garantisca user verification e che il private key non sia esportabile. Il TPM Windows soddisfa questi requisiti. Chrome, tuttavia, gestisce il ciclo di vita delle chiavi in modo che permette: wrapping arbitrario senza persistenza nominata, ri-registrazione senza attestazione di origine hardware, e esposizione di segreti master in memoria utente anziché in enclave isolata.
Il caso di eBay mostra che anche servizi che adottano passkey possono trascurare controlli fondamentali sul flag User Verified. La combinazione di implementazione client debole e validazione server incompleta crea una catena di fallimento che la promessa "phishing-resistant" non copre: il malware è già dentro l'endpoint.
Contesto: CVE-2026-34348 e il momento delle passkey
Nello stesso periodo, Microsoft ha rilasciato il 14 luglio 2026 un aggiornamento per CVE-2026-34348, una vulnerabilità del Windows Event Logging Service con CVSS 6.5 (MEDIUM) che espondeva dati passkey. Secondo le fonti contestuali, questa ricerca concettualmente correlata — condotta da Michael Grafnetter e associata al termine "Pass-the-Passkey" — tratta meccanismi tecnici differenti da quelli Unit 42. Il CVE 6.5 rappresenta un vettore separato nel medesimo ecosistema Windows, confermando che la superficie d'attacco delle passkey è attivamente esplorata.
Non risulta alcun CVE assegnato al 3 agosto 2026 per le tre tecniche documentate da Unit 42. Google non ha commentato pubblicamente la ricerca al momento della pubblicazione. Non emergono sovrapposizioni infrastrutturali che colleghino le tecniche Unit 42 al CVE-2026-34348 allo stato attuale.
Cosa fare adesso
Per gli sviluppatori di servizi che implementano passkey: validare rigorosamente il flag User Verified nelle risposte di autenticazione, rifiutando esplicitamente risposte con valore zero quando la policy richiede verifica dell'utente. Per le aziende in rollout passkey: valutare se la protezione endpoint — compresa la visibilità su processi che interagiscono con API crittografiche Windows e accesso ai database LevelDB di Chrome — copra lo scenario malware-già-presente. Per gli utenti Windows con Google Password Manager: il brief non documenta azioni correttive specifiche da parte di Google al 4 agosto 2026; il dossier non specifica se esistano versioni di Chrome non interessate o se correzioni siano state distribuite successivamente.
La ricerca non documenta sfruttamenti in-the-wild delle tre tecniche, ma il loro requisito di accesso locale — non remoto — le rende compatibili con la tipologia di compromissione più comune su endpoint Windows.
Perché la promessa delle passkey è a rischio di inflazione
Le passkey sono state presentate come eliminazione definitiva delle password e della loro debolezza umana. La ricerca Unit 42 dimostra che, nel più grande ecosistema passkey esistente, un compromesso endpoint riporta lo scenario al medesimo livello di rischio operativo: account sottratto, persistenza dell'accesso, assenza di segnali d'allarme. La differenza è che l'utente non ha una password da cambiare, e il Security Domain Secret non è ruotabile.
L'implementazione Google ha trasformato un protocollo progettato per hardware sicuro in un sistema di sincronizzazione cloud con garanzie attenuate. Finché il vendor non riprogetta la gestione del ciclo di vita chiavi e l'isolamento del SDS, le passkey in Chrome su Windows restano passkey di nome, password di fatto — con un solo punto di fallimento centralizzato in più.
Fonti
- https://www.hwupgrade.it/news/sicurezza-software/malware-senza-privilegi-entra-negli-account-protetti-da-passkey_157282.html
- https://windowsforum.com/windows-news.4/cve-2026-34348-windows-11-fixes-passkey-data-exposure.440578/
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.