Google Password Manager, tre attacchi minacciano account con passkey

Le passkey eliminano l’uso delle password durante le procedure di autenticazione, resistono al phishing tradizionale e impediscono il riutilizzo delle credenziali sottratte da altri servizi (la cosiddetta tecnica credential stuffing). Non rendono però invulnerabile il dispositivo sul quale operano. Una ricerca di Unit 42, il gruppo di analisi delle minacce di Palo Alto Networks, mostra come un malware già presente su Windows possa sfruttare alcuni meccanismi di Google Password Manager e Chrome per autenticarsi sugli account della vittima, sostituire una chiave di verifica o persino recuperare il segreto crittografico che protegge le passkey sincronizzate.

Introdotte pubblicamente nel 2022 sulla base degli standard FIDO2 e WebAuthn, le passkey hanno raggiunto circa 5 miliardi di credenziali attive secondo il rapporto FIDO Alliance pubblicato a maggio 2026. L’organizzazione stima inoltre che il 90% dei consumatori conosca la tecnologia e che il 75% l’abbia già abilitata su almeno un account.

La crescita si spiega facilmente: una passkey non contiene un segreto che l’utente possa digitare per errore in un sito falso e non può essere indovinata con attacchi brute force o a dizionario.

Come funzionano le passkey sincronizzate di Google

Una passkey è una credenziale asimmetrica legata a uno specifico servizio, definito in WebAuthn come relying party. Il dispositivo conserva la chiave privata, mentre il sito registra soltanto la chiave pubblica. Durante l’accesso il server genera una sfida casuale (challenge); l’autenticatore la firma e il servizio verifica la firma senza ricevere password o altri segreti riutilizzabili.

Google Password Manager permette di sincronizzare le passkey tra dispositivi Android e browser Chrome collegati allo stesso account Google. Prima della sincronizzazione, i dati risultano cifrati sul dispositivo. Su un nuovo computer l’utente può recuperarli tramite il PIN di Google Password Manager e i meccanismi di protezione associati all’account. Lo abbiamo spiegato nella guida su Google Password Manager.

Chrome per Windows utilizza inoltre un autenticatore cloud e alcune chiavi legate al dispositivo. Quando il computer dispone di un chip TPM (Trusted Platform Module), Chrome può appoggiarsi ad esso per proteggere le operazioni crittografiche e dimostrare al servizio Google che la richiesta arriva da una macchina precedentemente registrata. Il TPM, tuttavia, protegge una chiave dall’esportazione diretta; non garantisce automaticamente che ogni richiesta di firma corrisponda a un’azione consapevole dell’utente.

Unit 42 ha studiato proprio questa zona di confine. La ricerca riguarda Google Password Manager in Chrome su Windows con TPM e parte sempre da una condizione importante: un malware deve già essere in esecuzione nell’account della vittima. Non si tratta quindi di un attacco remoto che compromette da solo un PC aggiornato, né di una tecnica che consente di indovinare una passkey attraverso Internet.

Il malware può individuare gli account protetti da passkey

Il primo passaggio consiste nella ricognizione locale. Chrome conserva i record delle credenziali sincronizzate in un database creato, per ciascun profilo utente, sotto il percorso %LocalAppData%\Google\Chrome\User Data<Profile>\Sync Data\LevelDB.

Un processo eseguito con i normali privilegi dell’utente può leggere informazioni sufficienti per ricostruire quali servizi usano una passkey, i nomi utente associati, gli identificatori delle credenziali e il materiale della chiave privata in forma cifrata. In pratica, il malware non ottiene immediatamente le passkey utilizzabili, ma ricava una mappa molto precisa degli account da attaccare.

Pass-ta-key usa il TPM senza chiedere conferma all’utente

La prima tecnica illustrata dai ricercatori di Unit42 si chiama Pass-ta-key e sfrutta la chiave con cui Chrome dimostra l’identità del dispositivo al Google Cloud Authenticator. Su Windows il browser crea una chiave supportata dal TPM tramite le Cryptography API: Next Generation (CNG).

La chiave privata non lascia il TPM in chiaro. Chrome salva però sul disco un blocco chiamato NCRYPT_OPAQUE_KEY_BLOB, che permette al browser di richiamare la chiave quando deve firmare nuovi dati. Un malware eseguito con i privilegi dell’utente può recuperare questo dato e passarlo alle stesse API di Windows usate da Chrome.

In pratica, il codice malevolo chiede al TPM di firmare una richiesta al posto del browser. Non deve estrarre la chiave privata, ottenere privilegi amministrativi o mostrare la finestra di Windows Hello: la firma avviene sul PC della vittima e risulta associata al dispositivo corretto.

L’attaccante può quindi avviare un login, ricevere la sfida WebAuthn dal sito e farla elaborare dall’autenticatore cloud di Google. Il servizio riconosce il computer come registrato e produce una risposta crittograficamente valida.

Manca però un elemento: la prova che l’utente abbia autorizzato l’operazione con PIN, impronta digitale o riconoscimento del volto. WebAuthn segnala tale verifica attraverso il flag User Verified, indicato come UV. Nell’attacco Pass-ta-key il dispositivo risulta valido, ma il flag UV resta impostato a zero.

Il sito deve controllare che l’utente abbia davvero autorizzato il login

WebAuthn permette a un sito di richiedere esplicitamente la verifica dell’utente impostando userVerification su “required”. Il server deve però controllare anche la risposta ricevuta e rifiutare l’accesso quando il flag UV non risulta attivo.

Durante i test, GitHub ha bloccato correttamente il login generato con Pass-ta-key. eBay, invece, accettava inizialmente la risposta pur avendo richiesto la verifica dell’utente: il sito non controllava in modo adeguato il valore UV. Dopo la segnalazione di Unit 42, eBay ha corretto il comportamento.

Il punto è che una firma valida non dimostra automaticamente che una persona abbia sbloccato il dispositivo. Se il servizio non verifica il flag UV, il semplice possesso di un PC compromesso può bastare per superare un controllo che dovrebbe includere anche PIN o biometria.

Silver Pass-ta-key registra una chiave controllata dall’attaccante

Silver Pass-ta-key prova a superare anche i controlli di quei siti che accertano la configurazione del flag UV. Il malware non usa la chiave legittima di Windows Hello: induce Chrome a registrare presso Google una nuova chiave di verifica generata dall’attaccante.

Per avviare il processo, il malware elimina o altera lo stato locale dell’autenticatore cloud, ad esempio cancellando il file passkey_enclave_state. Chrome interpreta così il computer come un dispositivo da configurare nuovamente.

Durante questa procedura il browser può chiedere il PIN di recupero di Google Password Manager. La chiave definitiva collegata a Windows Hello non viene però sempre creata subito: Chrome può lasciare temporaneamente il dispositivo nello stato uv_key_pending e completare la configurazione al successivo utilizzo della passkey.

I ricercatori hanno sfruttato tale intervallo per registrare una chiave pubblica controllata dal malware. Secondo Unit 42, Google Cloud Authenticator non verificava in modo sufficiente che la nuova chiave provenisse davvero da Windows Hello o da hardware protetto. Una volta registrata, le firme prodotte dall’attaccante risultavano accompagnate dal flag UV attivo.

L’attacco diventa così più pericoloso di Pass-ta-key: il criminale può firmare le richieste dal proprio sistema, senza continuare a usare il TPM della vittima, e accedere anche ai siti che controllano correttamente la verifica dell’utente. Una compromissione temporanea del PC può quindi lasciare all’attaccante una credenziale riutilizzabile.

Golden Pass-ta-key recupera la chiave che protegge l’archivio

La terza metodologia di attacco, battezzata Golden Pass-ta-key, punta direttamente al segreto usato per cifrare le passkey sincronizzate in Google Password Manager. Tale valore, chiamato Security Domain Secret o SDS, è una chiave simmetrica di 32 byte che protegge le chiavi private conservate nell’archivio.

Sul disco il segreto compare soltanto in forma cifrata, con il nome wrapped_secret. Durante il recupero delle credenziali, però, Chrome deve ottenere il valore SDS per decifrare le passkey e renderle utilizzabili.

Unit 42 aveva inizialmente trovato il segreto in chiaro nei log FIDO accessibili dalla pagina chrome://device-log/FIDO. Google ha eliminato questa esposizione dopo la segnalazione: secondo i ricercatori, tuttavia, il valore continua a transitare nella memoria del processo Chrome durante le operazioni di recupero.

Un malware può quindi forzare una nuova registrazione del dispositivo e analizzare la memoria del browser nel momento in cui Chrome riceve il segreto. Se riesce a recuperare l’SDS, può decifrare i record presenti nel database locale e ottenere le chiavi private delle passkey.

A quel punto non serve più usare il TPM del sistema della vittima né mantenere una chiave fraudolenta registrata nel servizio Google. L’attaccante può trasferire le passkey su un altro sistema e usarle attraverso un autenticatore sotto il proprio controllo.

Secondo la ricerca, lo stesso SDS protegge anche le passkey aggiunte in seguito. Se il segreto non può essere ruotato o revocato, eliminare il malware e registrare nuovamente il dispositivo potrebbe non bastare: occorrerebbe sostituire le credenziali già esposte presso i singoli servizi online!

Cosa possono fare siti, sviluppatori e fornitori di password manager

L’intervento più immediato per i servizi web consiste nell’impostare userVerification su “required” quando il livello di rischio lo richiede e, soprattutto, nel verificare il flag UV restituito dall’autenticatore. La richiesta inviata dal sito esprime una preferenza o un requisito; non dimostra che la verifica abbia davvero avuto luogo.

I fornitori di gestori di credenziali dovrebbero invece applicare un’attestazione rigorosa alle nuove chiavi di identità e di verifica, impedendo che una chiave software arbitraria sostituisca quella protetta da TPM o Windows Hello. Anche la registrazione successiva alla cancellazione dello stato locale richiede controlli più forti: un file eliminato sul client non dovrebbe bastare ad aprire una finestra utile per ridefinire l’identità crittografica del dispositivo.

Un altro punto riguarda la separazione dei segreti. Il SDS non dovrebbe comparire nei log né diventare leggibile nel normale spazio di memoria del browser: una progettazione più robusta manterrebbe le operazioni di decifratura nell’enclave cloud o in un componente isolato, restituendo al client soltanto il risultato strettamente necessario.

Il database locale delle passkey e i file di onboarding meritano inoltre protezioni aggiuntive contro lettura e modifica da parte di processi estranei. Su Windows non è semplice isolare completamente due applicazioni avviate dallo stesso account, ma ACL più restrittive, servizi dedicati, processi sandbox e controlli sull’integrità dello stato possono aumentare sensibilmente il costo dell’attacco.

Cosa può fare concretamente l’utente

Per l’utente finale la priorità rimane la protezione dell’endpoint. Aggiornare Chrome, Windows e i prodotti di sicurezza riduce la probabilità che un infostealer o un trojan raggiunga i file e la memoria del browser. Conviene anche evitare l’esecuzione di programmi sconosciuti, falsi aggiornamenti e allegati che chiedono di disattivare Microsoft Defender o SmartScreen.

Richieste inattese del PIN di Google Password Manager durante un normale accesso con passkey dovrebbero destare qualche sospetto. Potrebbero derivare da una normale modifica del profilo o da un problema di sincronizzazione, ma rappresentano anche il comportamento atteso quando Chrome deve registrare nuovamente il dispositivo. In presenza di altri segnali anomali è prudente interrompere l’operazione, controllare le sessioni attive dell’account e svolgere le verifiche da un dispositivo affidabile.

Per gli account di maggior valore ha sempre senso conservare una seconda credenziale indipendente, ad esempio una chiave di sicurezza hardware FIDO2 non sincronizzata. Non elimina il rischio di compromissione del sistema, ma evita di affidare tutti i metodi di accesso allo stesso archivio cloud e allo stesso flusso di recupero.

Lo abbiamo evidenziato nell’articolo su come evitare il blocco dell’account Google prima che sia tardi.

Le passkey restano più sicure delle password, ma non sono una barriera assoluta

Pass-ta-key, Silver Pass-ta-key e Golden Pass-ta-key non dimostrano affatto che sia necessario tornare alle password. Una password può essere sottratta da una pagina di phishing, riutilizzata su più siti, intercettata da un infostealer o comprata in un archivio di credenziali compromesse. Le passkey eliminano gran parte di tali attacchi e mantengono un vantaggio netto.

La sicurezza delle passkey, però, non coincide soltanto con la robustezza della coppia di chiavi: dipende anche da chi può chiedere una firma, da come un nuovo dispositivo conquista la fiducia, da dove transita il segreto principale e da quanto scrupolosamente il servizio verifica quel singolo bit che attesta la presenza reale dell’utente.