Divulgazione di affiliazione - questo articolo contiene un link di affiliazione a un gestore di password. Se ti abboni tramite quel link riceviamo una commissione senza alcun costo aggiuntivo per te. Non cambia nulla di ciò che segue: i risultati qui sotto provengono da Unit 42 di Palo Alto Networks e dalla stampa tecnica, e sono attribuiti fonte per fonte.
Risposta breve: sì, le passkey si possono ancora usare in sicurezza, e lo dicono a chiare lettere i ricercatori che hanno pubblicato l'attacco. Il 3 agosto 2026, Unit 42 di Palo Alto Networks ha mostrato che un malware già in esecuzione su un PC Windows può dirottare le passkey sincronizzate tramite Google Password Manager. La loro stessa frase è quella da ricordare: "These attacks do not break the underlying cryptography." («questi attacchi non violano la crittografia sottostante»). Ciò che hanno violato è l'impianto attorno alla passkey, non la passkey.
Questa distinzione è tutta la storia, e la maggior parte dei titoli l'ha lasciata cadere.
Che cosa è stato effettivamente pubblicato
Arie Olshtein, ricercatore di Unit 42, ha pubblicato "Pass the Passkey: A Novel Attack Surface in Passwordless Authentication" il 3 agosto 2026. È un articolo tecnico di ricerca su blog, non uno studio sottoposto a revisione paritaria, e proviene da un fornitore commerciale di sicurezza, vale la pena dirlo apertamente, perché è dettagliato e credibile ma non è una parte terza neutrale.
Descrive tre tecniche, chiamate collettivamente attacchi Pass-ta-key.
Pass-ta-key, il malware preleva da disco o dalla memoria la chiave privata di identità del dispositivo in forma incapsulata, poi chiama le API Windows CNG (NCryptOpenStorageProvider, NCryptImportKey, NCryptSignHash) per far firmare il TPM per suo conto. Firma l'hash dell'handshake WebSocket e si spaccia per un'installazione legittima di Chrome presso l'autenticatore cloud di Google. Nessuno sblocco del dispositivo, nessuna interazione dell'utente, nessuna elevazione di privilegi. Da notare la sottigliezza: la chiave non lascia mai il TPM, semplicemente si fa lavorare il TPM per l'aggressore.
Silver Pass-ta-key, il malware cancella passkey_enclave_state per forzare una nuova registrazione del dispositivo, sfrutta lo stato transitorio uv_key_pending e registra la propria chiave di verifica utente. La falla è precisa: l'autenticatore cloud non convalida l'attestazione delle chiavi UV appena registrate, quindi non è in grado di stabilire se provengano da hardware sicuro. Risultato: un accesso riutilizzabile da un'altra macchina, senza il dispositivo della vittima.
Golden Pass-ta-key, la peggiore delle tre. Il Security Domain Secret, una chiave madre di 32 byte che protegge ogni passkey sincronizzata, viene estratto dalla memoria di processo di Chrome durante la nuova registrazione. Con essa un aggressore decifra i record delle credenziali memorizzate e si porta via ogni passkey sincronizzata sull'account.
I due fatti che rendono la cosa seria
Google ha rimosso il Security Domain Secret dai log diagnostici di Chrome dopo la divulgazione. Ma Unit 42 afferma che il segreto viene ancora inviato al client e resta accessibile nella memoria di processo di Chrome, riconosciuto, non corretto.
E non esiste alcun modo per ruotare o revocare quella chiave madre nell'implementazione attuale. Le passkey presenti e future restano protette dallo stesso segreto. È la parte più difficile di questa vicenda, e quella che non ha alcuna soluzione alternativa lato utente.
L'unica condizione che cambia tutto
Ognuna di queste tecniche presuppone un malware già in esecuzione sulla macchina. Lo dicono i ricercatori: "malware already existing on the victim's device during the initial stage." («un malware già presente sul dispositivo della vittima durante la fase iniziale»).
Frank Dickson di IDC ne ha dato la formulazione più chiara, su Computerworld: "This isn't passkeys getting hacked from across the internet. It's what [an attacker] does once they're already inside the house." («non si tratta di passkey violate attraverso Internet. È ciò che [un aggressore] fa una volta che è già dentro casa»).
Il perimetro è quindi stretto e specifico:
| Condizione | Richiesto |
|---|---|
| Sistema operativo | Windows |
| Browser | Chrome |
| Archivio credenziali | Google Password Manager (passkey sincronizzate) |
| Hardware | Macchina dotata di TPM |
| Prerequisito | Malware già in esecuzione in locale |
| Privilegi necessari | Livello utente, nessuna elevazione |
| Interazione dell'utente | Nessuna |
Non serve alcun phishing, nessuna estensione malevola, nessuna sessione rubata, nessun declassamento verso un altro fattore. E nessuno sfruttamento remoto: se la tua macchina è pulita, niente di tutto questo ti raggiunge.
iCloud Keychain di Apple, Windows Hello, 1Password e Bitwarden non sono stati testati. Unit 42 osserva che altri fornitori usano un'architettura di autenticatore cloud simile, il che è un avvertimento sull'architettura: non il riscontro che siano vulnerabili. Chiunque ti dica «tutte le passkey sono colpite» va oltre la ricerca.
Che cosa vale la pena cambiare
Se sei un privato. L'unico vero lucchetto qui è l'unico prerequisito: tenere il malware fuori dalla macchina. La raccomandazione di Unit 42 è di investire nella protezione degli endpoint e di trattare le passkey come uno strato di una strategia più ampia, non come un traguardo finale. Per gli account di maggior valore, email, banca, registrar del dominio, una chiave di sicurezza hardware è l'opzione legata al dispositivo che questa ricerca non tocca, perché nulla viene sincronizzato verso un'enclave cloud. È un compromesso, non un verdetto: guadagni resistenza a questa classe di attacchi e perdi la comodità della sincronizzazione tra dispositivi.
Se gestisci un servizio. La correzione concreta è lato server ed è indicata esplicitamente: richiedere userVerification e convalidare davvero il flag UV nella risposta di autenticazione. Non è un'ipotesi, eBay accettava autenticazioni senza verifica dell'utente mentre userVerification era impostato su required, e ha corretto il problema dopo il rapporto di Unit 42. GitHub ha respinto correttamente lo stesso attacco. Un'implementazione solida regge; una disomogenea no. Come ha riassunto l'analista Justin Greis su Computerworld: "The specification is sound, but the ecosystem implementing it is uneven." («la specifica è solida, ma l'ecosistema che la implementa è disomogeneo»).
Oltre a questo, le misure documentate dai ricercatori e dagli analisti citati su Computerworld: convalidare l'attestazione della chiave del dispositivo al momento della registrazione, monitorare gli usi anomali delle passkey, adottare EDR e ITDR, definire una politica esplicita sulle credenziali sincronizzate rispetto a quelle legate al dispositivo, e provare le procedure di recupero, perché il recupero e la nuova registrazione sono esattamente ciò di cui questi attacchi abusano.
Che cosa non bisogna concludere
Diverse affermazioni che circolano questa settimana non sono supportate dalla ricerca, e ripeterle sarebbe sbagliato:
- «Le passkey sono morte / compromesse.» Smentito per iscritto da Unit 42 e SecurityWeek.
- «La crittografia è stata violata.» Non lo è stata, esplicitamente.
- «Tornate alle password.» Nessuna fonte lo raccomanda, e reintrodurrebbe il phishing e il riutilizzo delle credenziali, proprio gli attacchi che le passkey eliminano.
- «È un CVE sfruttato attivamente.» Al 3 agosto non era stato assegnato alcun CVE, e non è stato segnalato alcuno sfruttamento in circolazione.
- «Anche Apple e Microsoft sono colpite.» Non testate. Non è la stessa cosa.
Il riassunto onesto appartiene alla stessa Unit 42: le passkey sono "a meaningful step forward in authentication security" («un passo avanti significativo nella sicurezza dell'autenticazione») perché eliminano i segreti condivisi e con essi intere classi di attacco. Questa ricerca non ribalta il quadro. Mostra che l'ecosistema costruito attorno alle passkey, registrazione, recupero, sincronizzazione cloud, merita lo stesso esame che la crittografia ha già ricevuto.
La lezione più profonda, sollevata da J. Wolfgang Goerlich su Computerworld, è quella da conservare: le passkey sincronizzate hanno reintrodotto un rischio di portabilità delle credenziali che gli autenticatori legati al dispositivo non hanno mai avuto. La comodità tra dispositivi ha un prezzo, e questa è la prima volta che lo vediamo con chiarezza.
Fonti
- Arie Olshtein, "Pass the Passkey: A Novel Attack Surface in Passwordless Authentication", Palo Alto Networks Unit 42, 3 agosto 2026, fonte primaria, fornitore commerciale di sicurezza.
- BleepingComputer, 3 agosto 2026, prima copertura, segnala che nessun CVE è stato assegnato.
- The Hacker News, 3 agosto 2026, «gli attacchi prendono di mira il codice attorno alla passkey».
- SecurityWeek, 5 agosto 2026, « That does not mean passkeys are broken » («questo non significa che le passkey siano compromesse»).
- Computerworld, Evan Schuman, 5 agosto 2026, commenti degli analisti (Dickson, Greis, Goerlich, Levine, Finkelstein).
- Biometric Update, 7 agosto 2026, posizione ufficiale della FIDO Alliance, nessuno sfruttamento in circolazione.
Dati e dichiarazioni verificati il 9 agosto 2026. A quella data Google non aveva rilasciato alcuna dichiarazione pubblica nel merito; è il punto che ha più probabilità di essere cambiato da allora.
★ Audit Cure53 2024 · ✓ Plan gratuit · Cross-platform
Un gestore con 2FA e passkey integrate → NordPassSalva TOTP e passkey · XChaCha20 · piano gratuito→Domande frequenti
Le passkey sono ancora sicure dopo la ricerca Pass-ta-key?
Sì, e lo dicono gli stessi ricercatori. Unit 42 di Palo Alto Networks afferma chiaramente che « These attacks do not break the underlying cryptography » («questi attacchi non violano la crittografia sottostante»). SecurityWeek aggiunge che « That does not mean passkeys are broken » («questo non significa che le passkey siano compromesse») né che le persone debbano smettere di usarle. Ciò che la ricerca dimostra è che un malware già in esecuzione su un PC Windows può abusare del meccanismo attorno alla passkey, la sincronizzazione cloud di Google, e non della passkey in sé. Le passkey restano un miglioramento reale rispetto alle password, perché eliminano il segreto condiviso su cui si basano il phishing e il credential stuffing.
Che cosa sfruttano esattamente gli attacchi Pass-ta-key?
Tre tecniche distinte, tutte pubblicate da Unit 42 il 3 agosto 2026. Pass-ta-key estrae la chiave di identità del dispositivo in forma incapsulata e usa le API Windows CNG per far firmare il TPM per conto dell'aggressore, spacciandosi per un'installazione legittima di Chrome presso l'autenticatore cloud di Google. Silver Pass-ta-key forza una nuova registrazione del dispositivo e registra la propria chiave di verifica utente, perché l'autenticatore cloud non convalida l'attestazione delle chiavi UV appena registrate. Golden Pass-ta-key estrae il Security Domain Secret, una chiave madre di 32 byte, dalla memoria di processo di Chrome: con essa è possibile decifrare ogni passkey sincronizzata sull'account.
Sono colpito anch'io?
Solo in presenza di un insieme preciso di condizioni, che devono essere vere tutte insieme: Windows, Chrome, passkey sincronizzate tramite Google Password Manager, una macchina dotata di TPM e soprattutto un malware già in esecuzione su quella macchina. Non c'è alcuno sfruttamento remoto: i ricercatori affermano che l'attacco richiede « malware already existing on the victim's device » («un malware già presente sul dispositivo della vittima»). L'analista di IDC Frank Dickson lo ha detto con chiarezza su Computerworld: non si tratta di passkey violate attraverso Internet, ma di ciò che un aggressore fa una volta che è già dentro casa.
Apple, Microsoft o i gestori di password di terze parti sono colpiti?
Non è stato stabilito, e sarebbe scorretto affermare il contrario. Unit 42 ha testato Google Password Manager su Chrome sotto Windows. iCloud Keychain, Windows Hello, 1Password, Bitwarden e altri non sono stati testati. Unit 42 osserva però che altri fornitori usano un modello di autenticatore cloud simile: è un avvertimento sull'architettura, non il riscontro di una vulnerabilità. Vanno considerati non testati, né sicuri né vulnerabili.
Google ha risolto il problema?
In parte, ed è importante essere precisi. Google ha rimosso il Security Domain Secret dai log diagnostici di Chrome dopo la divulgazione. Ma Unit 42 rileva che il segreto viene ancora inviato al client e resta accessibile nella memoria di processo di Chrome: un problema riconosciuto, non risolto. Peggio ancora, l'implementazione attuale non offre alcun modo per ruotare o revocare quella chiave madre, quindi le passkey presenti e future restano protette dalla stessa. Alla data di pubblicazione Google non aveva rilasciato alcuna dichiarazione pubblica nel merito, e la divulgazione non dimostra che tutte e tre le vie di attacco siano chiuse.
Devo smettere di usare le passkey sincronizzate e tornare alle password?
Nessuna fonte lo raccomanda, e nemmeno noi. Tornare alle password reintroduce esattamente gli attacchi che le passkey eliminano, phishing, riutilizzo, credential stuffing, in cambio della protezione da un attacco che richiede che la tua macchina sia già compromessa. La distinzione più utile, sollevata da J. Wolfgang Goerlich su Computerworld, è che le passkey sincronizzate hanno reintrodotto un rischio di portabilità delle credenziali che gli autenticatori legati al dispositivo non avevano. Per gli account di maggior valore, una chiave di sicurezza hardware è l'opzione legata al dispositivo.
Che cosa dovrebbe fare un'azienda?
La misura concreta indicata da ricercatori e analisti è lato server: richiedere userVerification e convalidare davvero il flag UV nella risposta di autenticazione. Quella lacuna non è teorica: eBay accettava autenticazioni senza verifica dell'utente pur avendo impostato userVerification su required, e ha corretto il problema dopo il rapporto di Unit 42. GitHub ha invece respinto correttamente lo stesso attacco, il che dimostra che un'implementazione corretta regge. Oltre a questo: convalidare l'attestazione della chiave del dispositivo, monitorare gli usi anomali delle passkey, adottare il rilevamento sugli endpoint e definire una politica esplicita sulle credenziali sincronizzate rispetto a quelle legate al dispositivo.
Questo attacco è stato usato contro persone reali?
Non è stato segnalato alcuno sfruttamento in circolazione. Biometric Update ha osservato il 7 agosto 2026 che si tratta di ricerca dimostrativa, e che al 3 agosto non era stato assegnato alcun CVE. Questo conta per il modo in cui reagire: è un motivo per rivedere come i tuoi account vengono recuperati e registrati di nuovo, non un motivo per farsi prendere dal panico.
