Le passkey sono state presentate — a ragione — come la risposta strutturale al phishing: una chiave crittografica che non si può indovinare, riutilizzare, scrivere su un post-it o consegnare per errore a un sito falso. Una ricerca pubblicata da Unit 42 di Palo Alto Networks mostra però che la promessa vale a una condizione tutt'altro che scontata: che il dispositivo dell'utente non sia già compromesso. I ricercatori hanno documentato tre tecniche, riunite sotto il nome Pass-ta-key, che permettono a un malware già in esecuzione su un PC Windows di dirottare le passkey sincronizzate tramite Google Password Manager in Chrome.

Nessuna delle tre rompe la crittografia delle passkey. Tutte e tre attaccano il contorno: come Chrome e l'autenticatore cloud di Google stabiliscono la fiducia in un dispositivo, come gestiscono l'onboarding e il recupero, come verificano che l'utente abbia davvero sbloccato la macchina.

Le tre tecniche

Pass-ta-key è la variante base. Il malware, anche senza privilegi amministrativi, abusa della chiave di identità del dispositivo custodita nel TPM per firmare una richiesta all'autenticatore cloud di Google. Il servizio la interpreta come proveniente dal computer legittimo dell'utente e restituisce un'assertion di autenticazione valida, utilizzabile per accedere all'account bersaglio. Non servono biometria, PIN, interazione dell'utente né sblocco del dispositivo. L'assertion però contiene il flag User Verified, che indica se la verifica dell'utente sia realmente avvenuta: dove il servizio lo richiede e lo controlla correttamente, l'attacco fallisce. Unit 42 riferisce che il tentativo contro GitHub è stato respinto proprio per questo, mentre contro eBay ha funzionato, perché il flag non veniva validato in modo corretto. eBay ha corretto il problema dopo la segnalazione.

Silver Pass-ta-key rimuove quell'ostacolo. Il malware forza Chrome a ri-registrare il dispositivo — invalidando la chiave di verifica esistente o cancellando il file locale con lo stato delle passkey — e durante la ri-registrazione registra una chiave di user verification controllata dall'attaccante, perché l'autenticatore cloud non verifica che la nuova chiave provenga da hardware attendibile. Da quel momento Google accetta come prova di sblocco dell'utente le richieste firmate dall'attaccante, che può autenticarsi da un'altra macchina, senza più bisogno di accedere al computer della vittima.

Golden Pass-ta-key è la più grave. Punta al Security Domain Secret (SDS), il segreto a 32 byte che cifra tutte le passkey sincronizzate sull'account. L'SDS viene inviato temporaneamente a Chrome quando un dispositivo si registra o recupera l'accesso. Unit 42 lo aveva inizialmente trovato in chiaro nei log FIDO interni del browser; Google lo ha rimosso dai log dopo la segnalazione, ma — scrivono i ricercatori — il segreto continua a essere inviato al client e resta temporaneamente accessibile nella memoria del processo Chrome, da cui può essere estratto forzando una ri-registrazione e sapendo cosa cercare. Con l'SDS l'attaccante decifra le chiavi private di tutte le passkey sincronizzate, le clona su un altro sistema e le usa per impersonare la vittima. Il dettaglio decisivo: l'implementazione attuale non prevede modo di ruotare o revocare quel segreto, quindi anche le passkey sincronizzate in futuro restano protette dalla stessa chiave, già in mano all'attaccante.

I nomi non sono casuali: richiamano i Silver Ticket e Golden Ticket di Kerberos, e la logica è la stessa — dalla singola autenticazione rubata alla persistenza che non si revoca.

Cosa significa per le aziende italiane

La prima reazione, davanti alla premessa "serve malware già attivo sulla macchina", è archiviare la notizia: se un infostealer gira sull'endpoint, ho comunque perso. È una scorciatoia che fa perdere il punto. La proposta di valore delle passkey è esattamente quella di sopravvivere al furto di credenziali: una password rubata si cambia, un token OTP intercettato scade. Qui invece l'attaccante si porta via una chiave che, allo stato attuale, non si può cambiare. La remediation dopo un incidente non è più "reset delle password", ed è una differenza che pesa nella scrittura dei piani di risposta.

Il tema è particolarmente concreto per il mercato italiano proprio adesso. Molte aziende stanno pianificando o avviando la migrazione alle passkey, spinte da due fattori convergenti: la richiesta di autenticazione a più fattori resistente al phishing che deriva dagli obblighi NIS2 per i soggetti essenziali e importanti, e la necessità del settore finanziario di irrobustire l'autenticazione forte oltre gli OTP via SMS. In questi progetti la scelta di default è quasi sempre la passkey sincronizzata nel password manager del browser o del sistema operativo, perché è gratuita, comoda e recuperabile.

La ricerca di Unit 42 non dice di fermare quei progetti: le passkey restano nettamente superiori alle password, e per la stragrande maggioranza degli utenti e degli scenari rappresentano un miglioramento netto. Dice però che va introdotta una distinzione che oggi molti piani di adozione non fanno: fra passkey sincronizzate, la cui sicurezza dipende dall'account cloud e dall'igiene dell'endpoint, e passkey device-bound su token hardware FIDO2, che non lasciano mai il dispositivo e non sono sincronizzabili. Per gli amministratori di dominio, per chi dispone bonifici, per chi accede a dati sanitari o a sistemi industriali, la passkey sincronizzata nel browser non è la scelta appropriata.

C'è poi un secondo pubblico che dovrebbe leggere questa ricerca con attenzione: chi sviluppa i servizi, non chi li usa. Banche, e-commerce, portali della PA e software house che hanno implementato l'autenticazione WebAuthn devono verificare che il proprio Relying Party richieda e validi effettivamente il flag di user verification. L'errore trovato su eBay è esattamente il tipo di difetto che un penetration test standard non intercetta, perché il flusso funziona correttamente per l'utente legittimo: sbaglia solo nel caso che conta.

Il contesto normativo

L'articolo 32 del GDPR chiede misure tecniche adeguate al rischio, e la valutazione di adeguatezza si sposta man mano che le tecniche di attacco evolvono: dopo una ricerca pubblica di questo tipo, affidare l'accesso a dati particolari a passkey sincronizzate su endpoint non presidiati diventa una scelta da motivare. Sul fronte della sicurezza, il D.lgs. 138/2024 di recepimento della NIS2 richiede ai soggetti in perimetro misure di autenticazione a più fattori e di gestione degli accessi proporzionate al rischio, e per le entità finanziarie il regolamento DORA impone requisiti analoghi con un livello di documentazione ancora più stringente.

Il risvolto pratico più scomodo riguarda la notifica: se le passkey di un dipendente vengono clonate e ne segue un accesso non autorizzato a dati personali, si tratta di una violazione da valutare per la notifica al Garante entro 72 ore e, per i soggetti NIS2, di un possibile incidente significativo da preallertare al CSIRT Italia entro 24 ore. Con l'aggravante che la misura di contenimento classica — invalidare le credenziali compromesse — oggi non è disponibile per l'SDS.

Cosa fare subito

  • Token FIDO2 hardware device-bound (chiavi fisiche) per amministratori, utenze privilegiate e ruoli ad alto impatto finanziario: non sono sincronizzabili e non sono esportabili.
  • Verificare lato applicazione che i propri servizi WebAuthn richiedano la user verification e ne validino il flag nella risposta, invece di limitarsi a richiederla nella policy di registrazione.
  • Aggiornare i playbook di incident response: la compromissione di un endpoint Windows con Chrome sincronizzato va trattata come compromissione di tutte le passkey sincronizzate su quell'account, con ri-enrollment delle credenziali, revoca di tutte le sessioni attive e revisione dei dispositivi fidati.
  • Su parco macchine gestito, impedire tramite policy la sincronizzazione del profilo Chrome con account personali e separare i profili aziendali da quelli privati.
  • Configurare l'EDR per rilevare accessi anomali alla memoria del processo Chrome e manipolazioni dei file di stato delle passkey nel profilo utente.
  • Non tornare indietro: la risposta corretta non è abbandonare le passkey per gli OTP via SMS, che restano molto più deboli, ma segmentare gli scenari d'uso in base al rischio.

Google, contattata al momento della pubblicazione della ricerca, non aveva ancora chiarito pubblicamente se e come tutte le criticità descritte siano state risolte. In assenza di un meccanismo di rotazione del segreto, questo resta il punto aperto più rilevante.