Pass-ta-key: cosa significa davvero l’attacco alle passkey di Google

Le passkey sono dunque insicure? È questa la domanda sollevata da Pass-ta-key.

Palo Alto Networks Unit 42 descrive tre catene di attacco con cui un malware può abusare delle passkey sincronizzate da Google, aggirare la verifica dell’utente e, nello scenario peggiore, estrarre tutte le chiavi private delle passkey di un account.

Nessuna tecnica viola WebAuthn, FIDO2 o la crittografia a chiave pubblica. Tutte richiedono che un malware sia già in esecuzione sul PC Windows della vittima. È un limite importante. Tuttavia, liquidare il problema dicendo che su un endpoint compromesso è già tutto perduto sarebbe troppo semplicistico: Golden Pass-ta-key mira a trasformare un’intrusione locale in un pacchetto esportabile e durevole di tutte le passkey sincronizzate, ben oltre il furto di una singola sessione.

La valutazione in breve

Sì, è un tema di sicurezza nuovo e autonomo. Non è però un motivo per abbandonare le passkey o tornare a usare esclusivamente password.

• Il protocollo regge: Origin Binding, challenge-response e crittografia asimmetrica non vengono violati.
• Viene attaccata un’implementazione concreta: Google Password Manager, Chrome, Windows e un TPM nella configurazione studiata da Unit 42.
• L’endpoint deve essere già compromesso: un sito qualsiasi non può eseguire l’attacco via Internet contro un computer pulito.
• Il danno potenziale resta notevole: si va da un’assertion di accesso generata in silenzio all’estrazione di tutte le chiavi private sincronizzate.
• Passkey sincronizzate e vincolate al dispositivo hanno profili di rischio diversi: sono entrambe passkey, ma non offrono lo stesso livello di assurance.
• Le password restano l’alternativa peggiore: possono inoltre essere rubate con il phishing, riutilizzate, indovinate o sottratte da database server.

La mia valutazione è quindi: ambito tecnico ristretto e prerequisiti impegnativi, ma impatto potenzialmente molto elevato in caso di successo.

Ambito tecnico ed evidenze

Al 31 agosto 2026, il quadro documentato comprende i flussi di Unit 42, la specifica WebAuthn, la documentazione Google, l’issue pubblico di Chromium e le indicazioni NIST per gli autenticatori sincronizzabili. Si aggiungono Pass-the-Passkey di SpecterOps, CVE-2026-34348, il downgrade FIDO di Proofpoint e le analisi di Expel e SquareX.

La ricerca è stata pubblicata il 3 agosto e aggiornata da Unit 42 il 14 agosto. Riguarda espressamente Google Password Manager in Chrome su Windows, su dispositivi dotati di Trusted Platform Module. Altri browser, sistemi e provider possono presentare questioni architetturali simili, ma questi tre attacchi non sono stati dimostrati altrove.

Non è documentata alcuna campagna attiva che sfrutti queste tecniche specifiche. Le evidenze consistono in ricerca, Proof of Concept e Responsible Disclosure. Una dimostrazione tecnica non equivale automaticamente a uno sfruttamento su larga scala.

Cosa protegge davvero una passkey

Una passkey non è una password molto lunga, ma una credenziale WebAuthn basata sulla crittografia asimmetrica.

private key -> remains with the authenticator
public key  -> is registered with the online service

La Relying Party conserva la chiave pubblica insieme a Credential ID e account. Al login invia un challenge nuovo e casuale. L’autenticatore firma dati che legano il challenge al contesto del sito chiamante, quindi il server verifica la firma.

La chiave privata non viene trasmessa come una password. Una violazione del servizio fornisce idealmente solo chiavi pubbliche, inutili per produrre firme valide. Inoltre, il legame con Relying Party ID e origine web impedisce a una passkey per example.com di generare su un dominio simile un’assertion valida per example.com. L’utente non possiede un segreto da digitare sul sito sbagliato o comunicare al telefono.

Questo significa resistente al phishing. NIST richiede che un verifier fraudolento non ottenga né il segreto né una risposta riutilizzabile presso il servizio legittimo. WebAuthn lo garantisce tramite il legame crittografico al nome del verifier. Pass-ta-key non modifica questa proprietà: il malware si trova già sul dispositivo considerato affidabile.

User Presence e User Verification non sono la stessa cosa

• User Presence, UP: l’utente ha eseguito un’azione di presenza, per esempio toccare una security key o confermare una finestra.
• User Verification, UV: l’autenticatore ha verificato localmente l’utente tramite Windows Hello, PIN o biometria.

L’assertion riporta questi risultati nei flag di authenticatorData. Se il server richiede userVerification: "required", deve controllare che il flag UV ricevuto sia impostato. Unit 42 non è riuscita a completare l’attacco semplice contro GitHub perché mancava UV. Su eBay il login riusciva inizialmente nonostante la richiesta, finché la verifica server non è stata corretta.

Una firma crittograficamente corretta non basta sempre per una MFA implementata correttamente. La Relying Party deve verificare quali condizioni l’autenticatore abbia davvero confermato.

Perché la sincronizzazione amplia il perimetro di fiducia

Una passkey vincolata a un dispositivo resta su uno specifico autenticatore. Una passkey sincronizzata deve essere cifrata, trasportata e ripristinata su altri dispositivi autorizzati.

Relying Party
    |
browser and WebAuthn client
    |
local platform authenticator
    |
passkey manager and recovery logic
    |
cloud sync and additional devices

Ogni livello richiede regole proprie per fiducia del dispositivo, onboarding, recovery, cifratura e revoca. Per questo NIST tratta separatamente gli autenticatori sincronizzabili: possono essere adatti fino ad Authentication Assurance Level 2, mentre AAL3 richiede chiavi non esportabili protette dall’hardware o un autenticatore separato. Le passkey sincronizzate non sono deboli, ma comodità e portabilità creano un modello di assurance diverso. Pass-ta-key colpisce proprio questo perimetro aggiuntivo.

L’ambito esatto della ricerca

I prerequisiti sono chiari: Google Password Manager gestisce le passkey, Chrome gira su Windows, il dispositivo possiede un TPM, il malware è già attivo nel contesto utente, l’ambiente Google è configurato e alcune varianti devono leggere dati Chrome, modificare stati o ispezionare la memoria del processo.

Non è stato dimostrato né un attacco universale contro ogni passkey né che un attaccante remoto possa estrarre una chiave WebAuthn dal TPM senza compromettere prima l’endpoint. La formulazione precisa è: Unit 42 ha dimostrato tre catene contro i meccanismi di fiducia, onboarding e recovery delle passkey Google sincronizzate su endpoint Windows compromessi.

Fase zero: la mappa locale delle passkey

Prima di ogni variante, il malware legge il database locale di sincronizzazione di Chrome. I record WebauthnCredentialSpecifics includono Relying Party, username, Credential ID e materiale cifrato delle chiavi private.

%LocalAppData%\Google\Chrome\User Data\<Profile>\Sync Data\LevelDB

Nel test non servivano privilegi elevati. Le chiavi non erano in chiaro, ma i metadati rivelavano servizi, account e Credential ID da colpire. Un infostealer può quindi creare un inventario e selezionare gli account più importanti.

Pass-ta-key: un’assertion valida senza azione dell’utente

La prima variante abusa dell’Identity Key con cui Chrome prova a Google Cloud Authenticator l’identità del dispositivo Windows. Chrome crea una chiave supportata dal TPM ed esporta quella privata tramite Windows CNG come NCRYPT_OPAQUE_KEY_BLOB, riutilizzabile crittograficamente sullo stesso TPM.

La protezione crittografica non risolve automaticamente l’autorizzazione. Malware nel normale contesto utente poteva leggere wrapped_identity_private_key o recuperarlo dalla memoria di Chrome e chiamare Windows CNG. Il TPM firma perché la richiesta proviene tecnicamente dal dispositivo corretto, senza sapere se l’API sia stata invocata da Chrome o dal malware.

attacker requests a fresh challenge from the online service
    -> malware on the victim PC uses the TPM-bound identity key
    -> Google Cloud Authenticator accepts the device identity
    -> Cloud Authenticator creates a valid passkey assertion
    -> attacker submits the assertion to the online service

Il malware usa così dispositivo e cloud come servizio di firma, senza necessariamente esportare la passkey. Il limite è il flag UV: l’Identity Key prova il possesso del dispositivo, non una verifica PIN o biometrica. Un servizio che richiede e controlla UV deve rifiutare UV = 0. Molti servizi usano però preferred o verificano male la risposta, riducendo di fatto il login all’accesso all’identità del dispositivo.

Silver Pass-ta-key: l’attaccante registra la propria identità UV

Silver supera quel limite senza violare Windows Hello. Il malware fa dimenticare lo stato del dispositivo o elimina passkey_enclave_state, forzando il re-onboarding. Su Windows, Chrome può prima usare il PIN di recovery di Google Password Manager e impostare uv_key_pending; la vera UV Key viene creata all’uso successivo.

La vittima deve inserire il PIN GPM nel processo inatteso, ma il malware non deve rubarlo. L’attaccante genera una coppia di chiavi e invia la propria pubblica come nuova UV Key. Secondo Unit 42, Cloud Authenticator non verificava che provenisse da hardware affidabile e la associava alla legittima identità del dispositivo.

Da allora l’attaccante può firmare autonomamente. Cloud Authenticator interpreta la firma come verifica locale e crea assertions con UV, anche con il PC della vittima offline. L’issue Chromium «GPM Passkeys Are Vulnerable to User Verification Key Abuse» risultava WAI al momento della mia verifica. La regola architetturale resta valida: onboarding e recovery che associano nuove chiavi affidabili sono eventi di autenticazione critici.

Golden Pass-ta-key: dal cloud a chiavi esportabili

La variante più grave mira al Security Domain Secret, SDS, un segreto di 32 byte che protegge le chiavi private sincronizzate di un account Google Password Manager. Il client dovrebbe avere solo un wrapped_secret cifrato, decifrato da Cloud Authenticator con una chiave specifica del dispositivo.

Durante onboarding e recovery, però, nuovi dispositivi devono rientrare nella Security Domain. Unit 42 ha scoperto che Chrome riceve il SDS in forma accessibile al client. Inizialmente appariva persino nel log diagnostico FIDO di Chrome. Google ha rimosso quella voce, ma il SDS passa ancora per la memoria del processo durante l’operazione.

Il malware deve forzare questo percorso e leggere la memoria al momento giusto:

1. Forza un nuovo onboarding.
2. Attende la creazione o modifica dello stato locale dell’enclave.
3. Legge la memoria di Chrome e cerca il SDS.
4. Lo combina con i record di sincronizzazione già acquisiti.
5. Decifra le chiavi private delle passkey.
6. Un autenticatore indipendente dal dispositivo della vittima può generare assertions valide.

Una sessione rubata può scadere o essere revocata. Golden mira invece a tutte le chiavi già sincronizzate. Unit 42 afferma inoltre che lo stesso SDS protegge passkey future e che nell’architettura studiata non era visibile un metodo per ruotarlo o revocarlo. Ciò non dimostra che ogni provider usi lo stesso schema né che Google non possa cambiarlo.

Perché il malware locale non rende irrilevante l’attacco

Chi può eseguire malware su un PC autenticato può già rubare cookie, leggere il browser, manipolare transazioni, esfiltrare file o agire nell’account. Nessuna autenticazione può fidarsi senza limiti di un client compromesso. Il furto di segreti da browser e password manager fa da anni parte del repertorio degli infostealer.

La ricerca fornisce tuttavia elementi concreti: un processo non privilegiato usava per firmare una chiave Chrome vincolata al TPM; il confine dispositivo/utente dipendeva dal flag UV; il re-onboarding permetteva una UV Key ostile; il segreto centrale appariva prima nei log e poi in memoria; il percorso peggiore rendeva riutilizzabili le chiavi fuori dal dispositivo; il contatore di firma spesso non segnala in modo affidabile la clonazione di credenziali sincronizzate tra più dispositivi.

«Endpoint compromesso» è un prerequisito, non una descrizione completa del danno. In Incident Response, una sessione temporanea e materiale di chiave privata durevole per molti servizi sono problemi molto diversi.

Pass-ta-key è solo una parte della nuova superficie di attacco

Le ricerche del 2025 e 2026 mostrano più percorsi senza violare matematicamente le chiavi: Pass-ta-key abusa di sincronizzazione e recovery dopo l’infezione; Pass-the-Passkey unisce un’assertion registrata a una falla di replay server; il downgrade FIDO sfrutta un fallback soggetto a phishing; Passkeys Pwned richiede estensione o script malevolo; gli infostealer rubano la sessione già autenticata.

Tutti colpiscono un livello di fiducia intorno a WebAuthn, non la crittografia: recovery, validazione server, browser o sessione. Una violazione del protocollo metterebbe in discussione ogni implementazione conforme; questi casi richiedono difese diverse.

Pass-the-Passkey: quando un’assertion valida è riutilizzabile

Per Black Hat USA 2026, SpecterOps ha identificato tre vulnerabilità in Windows 11 e Microsoft Entra ID e oltre 20 tecniche. Windows registrava assertions WebAuthn complete in Microsoft-Windows-WebAuthN/Operational, inclusi Credential ID, challenge, dati dell’autenticatore e firma. Entra ID le accettava nuovamente entro una finestra limitata.

Windows logs a complete assertion
    -> an attacker reads it
    -> the verifier does not bind the challenge and assertion tightly enough to the session
    -> the same signed response is accepted again

CVE-2026-34348 identifica la parte Windows. Il 14 luglio 2026 Microsoft ha ridotto a pochi byte la firma nei log, eliminando la fonte del replay. Ha inoltre introdotto controlli dei contatori per alcune security key FIDO2, ma credenziali di piattaforma o sincronizzate possono restituire sempre zero o condividere lo stato.

Le assertions non devono finire nei log. I challenge devono essere casuali, brevi, monouso e vincolati alla sessione. Un’altra tecnica riguarda il Parent-Window-Handle dell’API WebAuthn Windows: un processo locale può far sembrare una finestra autentica di passkey appartenente al browser o al client email. Le richieste inattese vanno quindi trattate come push MFA inattesi.

Il fallback più debole stabilisce il livello reale

Nel 2025 Proofpoint ha dimostrato un downgrade FIDO contro Entra ID. Un flusso Evilginx modificato si presentava come browser senza supporto FIDO; la piattaforma offriva SMS, OTP o un’altra alternativa soggetta a phishing, consentendo al flusso Adversary-in-the-Middle di rubare credenziali e sessione.

Origin Binding non viene aggirato: WebAuthn non inizia affatto. Serve un metodo più debole ancora abilitato e non è documentato uno sfruttamento reale. Una policy è resistente al phishing solo se login, recovery e helpdesk non accettano percorsi vulnerabili per quel livello di protezione.

Il browser fa parte del modello di sicurezza

Con Passkeys Pwned, SquareX mostra che un’estensione malevola o script nel browser possono influenzare navigator.credentials.create() e navigator.credentials.get(). Durante la registrazione, l’utente può vedere un vero dialogo biometrico mentre viene associata una credenziale controllata dall’attaccante.

Non è un exploit universale: estensione o script devono già intervenire nel percorso WebAuthn. Ma estensioni, Content Scripts e proxy WebAuthn appartengono alla Trusted Computing Base. Allowlist e controllo delle API privilegiate proteggono anche l’identità.

Le passkey proteggono il login, non automaticamente la sessione

Dopo il login il servizio usa in genere cookie o token. Se un infostealer li ruba e il server li accetta da un altro dispositivo, non servono password o passkey. È oggi un percorso più pratico di molti Proof of Concept.

Servono quindi conservazione sicura dei token, durata basata sul rischio, riautenticazione, revoca e possibilmente legame crittografico al dispositivo. Dire che «la MFA è stata aggirata» è impreciso: la MFA ha funzionato, il suo risultato è stato rubato dopo.

PoisonSeed mostra quanto rapidamente la ricerca diventa hype

Nel luglio 2025 Expel annunciò inizialmente che un QR code legittimo inoltrato tramite phishing poteva dirottare la Cross-Device Authentication. Pochi giorni dopo ritirò l’affermazione e si scusò.

Il controllo di prossimità locale non era stato superato: senza prossimità il flusso scadeva, tutte le richieste MFA fallivano e l’attaccante non otteneva accesso. Una comunicazione rigorosa distingue account takeover osservato, Proof of Concept riproducibile, attacco teorico e ipotesi confutata.

La mia valutazione di sicurezza

L’ambito tecnico è limitato a Google Password Manager in Chrome su Windows con TPM. La probabilità è medio-bassa perché il malware deve già essere attivo e manipolare stati o memoria. L’impatto può essere alto o molto alto: account takeover, accesso remoto persistente o estrazione di più chiavi. Il rischio per il protocollo resta basso.

Per un utente normale, una passkey sincronizzata resta generalmente più sicura di una password con SMS o TOTP, eliminando molti percorsi di phishing, Credential Stuffing e furto di password. Per amministratori, approvazioni finanziarie, produzione e sistemi regolamentati, una chiave di piattaforma legata al dispositivo o una security key FIDO2 separata può offrire un confine più adeguato. È sicurezza graduata, non un rifiuto della sincronizzazione.

Cosa devono verificare i gestori di servizi web

I server dovrebbero:

• impostare userVerification: "required" quando necessario e controllare UV in authenticatorData,
• validare completamente challenge, Origin, Relying Party ID e firma,
• rendere ogni challenge casuale, breve, monouso e vincolato alla sessione,
• evitare nei log assertions, firme e artefatti riutilizzabili,
• registrare creazione e rimozione delle passkey e account recovery come eventi ad alto rischio,
• richiedere forte riautenticazione prima di aggiungere autenticatori agli account privilegiati,
• raccogliere ove possibile provenienza e proprietà dell’autenticatore,
• valutare attestation e autenticatori gestiti per i casi ad alta sicurezza,
• rilevare cambi insoliti di dispositivo o posizione e nuove associazioni,
• revocare le sessioni dopo modifiche rischiose e riautenticare azioni critiche,
• usare sessioni vincolate al dispositivo quando il supporto è affidabile.

Una libreria WebAuthn consolidata riduce gli errori, ma la configurazione va verificata. eBay mostra l’effetto di un flag ignorato; Pass-the-Passkey quello di un legame scorretto tra challenge e sessione.

Cosa devono cambiare le aziende nei rollout

Un progetto passkey è contemporaneamente IAM, endpoint, browser e recovery. Gli account ordinari possono usare passkey sincronizzate su dispositivi gestiti con protezione endpoint e Conditional Access. Gli account sensibili richiedono autenticatori gestiti o sincronizzazione limitata. Admin, Break Glass e altri account di alto valore dovrebbero usare security key FIDO2 separate, recovery strettamente controllato e nessuna sincronizzazione cloud non gestita.

Le aziende devono inoltre aggiornare Chrome e Windows, verificare CVE-2026-34348, disciplinare l’archiviazione tramite Enterprise Policies, applicare allowlist alle estensioni, monitorare i proxy WebAuthn, estendere EDR e Application Control ai processi utente, rilevare accessi ai database sync e dump di Chrome, indagare modifiche a passkey_enclave_state, trattare richieste PIN di recovery inattese come allarmi, testare perdita e recupero, eliminare fallback soggetti a phishing, controllare prompt e nuove credenziali e inventariare le passkey sincronizzate o vincolate.

Se l’autenticatore vive nel browser e nel client, Endpoint Detection fa parte del modello di autenticazione.

Cosa devono fare ora gli utenti

Non c’è motivo di eliminare preventivamente le passkey. Occorre aggiornare Chrome e Windows, usare solo software ed estensioni affidabili, mantenere Windows Hello e l’antimalware, rifiutare richieste inattese, controllare dispositivi e passkey, valutare una security key per gli account più importanti e isolare qualsiasi endpoint sospetto.

In presenza di malware, stati Chrome manipolati o dump di memoria, cambiare password non basta. Bisogna ricostruire o bonificare l’endpoint, revocare le sessioni, verificare recovery, rimuovere passkey sconosciute e registrare di nuovo autenticatori affidabili.

Per un possibile incidente Golden, non è documentata una semplice rotazione SDS per l’utente. Non si deve promettere che cambiare PIN o una sola passkey risolva tutto. Dopo la bonifica registrerei nuove credenziali vincolate al dispositivo, eliminerei quelle sincronizzate precedenti e coinvolgerei il provider o il team Incident Response.

La vera lezione

Le passkey non proteggono da ogni compromissione. Risolvono un problema enorme: le persone non consegnano più un segreto riutilizzabile a un server o a un sito falso. La sincronizzazione aggiunge però cifratura delle chiavi, fiducia del dispositivo e recovery, dove possono esistere errori anche se WebAuthn è corretto.

Dichiarare fallite le passkey sarebbe sbagliato, come banalizzare ogni attacco dopo un’infezione locale. Bisogna continuare il rollout con promesse precise: le passkey sincronizzate eccellono contro il phishing; le security key vincolate al dispositivo offrono un confine più forte agli account di valore; nessun autenticatore sostituisce un endpoint pulito, recovery controllato e verifiche server corrette.

Le passkey hanno chiuso molto meglio la porta al phishing. Pass-ta-key ricorda che un attaccante già dentro casa richiede un’altra difesa.

Alla prossima,
Joe

FAQ