Le passkey hanno superato da tempo la fase della curiosità tecnica: oggi rappresentano una delle risposte più concrete al problema storico delle password rubate, riutilizzate e vulnerabili agli attacchi phishing. Eppure una parte dei grandi servizi online continua a non offrire agli utenti la possibilità di accedere mediante l’uso di passkey o le propone non come prima scelta. Scott Helme, ricercatore di sicurezza noto anche per il progetto Why No HTTPS realizzato nel 2017 con Troy Hunt (Have I Been Pwned), ha deciso di creare un sito che raccoglie tutte le piattaforme online che ancora non hanno scelto di abbracciare le passkey: Why No Passkeys.
Le password restano il punto debole di moltissimi account, mentre gli attacchi basati su credenziali rubate, credential stuffing e finte pagine di login sono, purtroppo, sempre più frequenti.
Il dato che ha accompagnato il lancio del progetto Why No Passkeys è piuttosto chiaro: 7 dei primi 25 siti globali non risultano ancora compatibili con le passkey, cioè il 28% delle destinazioni più visitate che presuppongono una procedura di accesso.
Tra i nomi evidenziati compaiono servizi di enorme visibilità come Instagram, Netflix, Spotify: non piccole realtà prive di team dedicati alla sicurezza, ma piattaforme che influenzano le abitudini di accesso di centinaia di milioni di persone.
Perché le passkey cambiano davvero il modello di accesso
Una passkey non è una password più lunga né un codice temporaneo più comodo. Nasce dalle specifiche FIDO2 e WebAuthn e usa crittografia a chiave pubblica: durante la registrazione il dispositivo dell’utente crea una coppia di chiavi, una pubblica e una privata. Il servizio conserva la chiave pubblica; la chiave privata resta nel dispositivo, oppure nel gestore di passkey scelto dall’utente, e non deve mai essere comunicata al sito.
Quando l’utente effettua l’accesso, il server invia una sfida crittografica o challenge: il dispositivo la firma usando la chiave privata solo dopo una verifica locale, per esempio impronta digitale, riconoscimento facciale, PIN del sistema o chiave di sicurezza fisica. Il sito verifica la firma con la chiave pubblica già registrata. In pratica non esiste un segreto condiviso da digitare, trasmettere o memorizzare in un database lato server.
Le passkey eliminano quindi alcune classi di attacco alla radice: se un criminale crea una pagina falsa che imita un servizio legittimo (phishing), il browser e l’autenticatore legano la credenziale al dominio corretto, cioè al Relying Party previsto: la passkey non funziona sua piattaforma diversa da quella a cui si riferisce. Allo stesso modo, una violazione del database del servizio non consegna agli aggressori password riutilizzabili: il server possiede solo chiavi pubbliche, non segreti validi per accedere e rubare identità altrui.
WebAuthn, FIDO2 e il ruolo del dominio
Come accennato in precedenza, la base tecnica per le passkey è WebAuthn, standard W3C che permette alle applicazioni web di creare e usare credenziali a chiave pubblica tramite il browser.
Le operazioni principali passano dalle funzioni del browser navigator.credentials.create() in fase di registrazione e navigator.credentials.get() in fase di autenticazione. Al livello più basso, il browser avvia una comunicazione sicura con un autenticatore: può trattarsi del modulo sicuro integrato nel computer o nello smartphone, di un TPM, di una Secure Enclave, di un Secure Element, oppure di una chiavetta esterna compatibile.
FIDO2 comprende WebAuthn e i protocolli CTAP (Client to Authenticator Protocol), cioè il canale con cui il client comunica con gli autenticatori, anche dispositivi esterni come chiave di sicurezza USB, NFC o Bluetooth.
“Supportare le passkey” può comunque voler dire cose diverse. Un servizio può consentire l’accesso completamente passwordless, quindi senza chiedere più la password. Oppure può usare la passkey come secondo fattore, lasciando la password come primo passaggio. Dal punto di vista dell’esperienza utente e della superficie d’attacco non è la stessa cosa: nel secondo caso una parte del rischio legato alla password rimane, anche se la passkey rafforza molto la fase di conferma.
Why No Passkeys: una lista pubblica per spingere l’adozione
Why No Passkeys mostra i siti più popolari che supportano o non supportano le passkey. C’è una classifica globale Top 25 e ci sono report per Paese, così da capire quanto sia diffusa l’adozione nei siti più visitati in una determinata area geografica.
Se Google, Apple, Microsoft o Amazon propongono passkey in modo visibile, milioni di persone iniziano a considerarle un metodo di accesso ordinario; se invece Instagram, Netflix o Spotify non le espongono chiaramente, il messaggio implicito è che siano ancora opzionali.
Il sito distingue, quando possibile, tra supporto passwordless e supporto usato solo come autenticazione a due o più fattori: è una distinzione importante per chi valuta la maturità di ciascuna piattaforma.
Helme spiega che per le liste globali e statunitensi usa Cloudflare Radar, mentre per le classifiche per Paese si appoggia a Tranco, che abbiamo presentato nell’articolo sull’autocompletamento automatico su oltre 240 nomi di domini Internet.
Le passkey non cancellano tutti i rischi
Sarebbe sbagliato descrivere le passkey come una soluzione magica: aumentano enormemente la resistenza al phishing, ma non proteggono da ogni scenario, come abbiamo spiegato in un articolo di approfondimento sul perché il meccanismo passkey può incepparsi.
Se un dispositivo risulta compromesso, se un malware opera nella sessione già autenticata, se il processo di recupero account rimane debole o se il supporto clienti può essere ingannato con social engineering, il rischio non scompare.
Vale la pena approfondire l’ultimo punto: un aggressore potrebbe contattare l’assistenza fingendosi il proprietario dell’account, dichiarare di aver perso il dispositivo e tentare di ottenere la rimozione della passkey o il ripristino dell’accesso. In quel caso il punto debole non sarebbe la crittografia, ma la procedura usata dal servizio per verificare l’identità dell’utente.
Un altro tema riguarda la sincronizzazione. Molte passkey moderne sono multi-device e possono sincronizzarsi tramite provider come Apple, Google, Microsoft o gestori di password terzi. La FIDO Alliance considera questa caratteristica essenziale per evitare che il primo accesso su un nuovo dispositivo torni a essere un passaggio fragile basato su password o recupero email. Ma la sincronizzazione introduce anche scelte di fiducia: l’utente deve poter capire dove risiedono le credenziali, come sono protette e come recuperarle in caso di perdita dell’account principale.
Per le aziende, poi, l’implementazione corretta richiede attenzione. Bisogna progettare enrollment, revoca, cambio dispositivo, account recovery, gestione delle chiavi hardware, policy per utenti ad alto rischio, telemetria sugli errori di autenticazione e test su browser diversi. Una passkey mal integrata non è per forza insicura, ma può diventare frustrante; e quando l’accesso diventa frustrante, gli utenti cercano scorciatoie e alternative.