Passkey: come funzionano davvero e perché resistono al phishing
Le passkey stanno comparendo sempre più spesso nelle impostazioni di sicurezza di smartphone, computer, browser e servizi online. A prima vista potrebbero sembrare soltanto un sistema più comodo per entrare in un account: niente password da ricordare, basta utilizzare il PIN del dispositivo, l’impronta digitale oppure il riconoscimento del volto.
In realtà il cambiamento è molto più profondo.
Una passkey non è una password conservata meglio e non è nemmeno una password molto lunga nascosta dentro il telefono. Il sistema sostituisce il classico segreto condiviso con un meccanismo basato sulla crittografia a chiave pubblica: il servizio conserva una chiave pubblica, mentre la componente privata necessaria all’autenticazione rimane sotto il controllo dell’autenticatore o del gestore delle credenziali.
Questa architettura cambia anche il rapporto con il phishing. Con una password possiamo essere convinti a digitare il nostro segreto in una pagina falsa. Una passkey viene invece associata al servizio per il quale è stata creata e il browser o il sistema operativo partecipano alla verifica del contesto nel quale può essere utilizzata.
Non stiamo parlando di una tecnologia proprietaria di Google, Apple o Microsoft. Le passkey utilizzano gli standard FIDO, basati su WebAuthn e CTAP. FIDO Alliance descrive WebAuthn e CTAP come le componenti che insieme costituiscono FIDO2. Il 25 agosto 2026 Web Authentication Level 3 è diventato ufficialmente una Recommendation del W3C.
Vediamo quindi cosa viene realmente creato, cosa conserva il sito, cosa rimane sul nostro dispositivo e perché questa tecnologia può offrire una protezione molto diversa rispetto alla tradizionale password.
Tabella dei contenuti
Passkey: che cosa sono realmente
Una passkey è una credenziale crittografica utilizzata per autenticare un utente presso uno specifico servizio.
Quando viene creata, il sistema genera una coppia di chiavi matematicamente correlate: una chiave pubblica e una chiave privata.
La chiave pubblica può essere comunicata al servizio e conservata sul server. Non costituisce, da sola, il segreto necessario per accedere all’account.
La chiave privata svolge invece il compito fondamentale: viene utilizzata per produrre la prova crittografica richiesta durante l’autenticazione. Non deve essere trasmessa al server come accade con un segreto che l’utente conosce e inserisce manualmente.
Google descrive lo stesso principio nella propria documentazione: durante la creazione viene generata una coppia pubblica/privata, mentre il sito conserva la componente pubblica. Dai soli dati presenti sul server non è possibile ricavare semplicemente la chiave privata necessaria per autenticarsi.
Possiamo semplificare il concetto immaginando che il server non chieda più:
“Qual è il segreto che conosci?”
La domanda diventa piuttosto:
“Puoi dimostrare di controllare la chiave privata corrispondente alla chiave pubblica che ho registrato?”
La differenza non è soltanto terminologica. È un modello di autenticazione diverso.
Come funzionano le passkey durante la registrazione
Quando abilitiamo una passkey per un account, il servizio prepara una richiesta WebAuthn.
La richiesta contiene, tra le altre informazioni, l’identità della Relying Party, i dati necessari per collegare la credenziale all’utente, i parametri crittografici accettati e una challenge generata appositamente per quell’operazione.
La Relying Party, generalmente abbreviata in RP, è il servizio presso il quale vogliamo autenticarci.
WebAuthn definisce credenziali a chiave pubblica specificamente circoscritte a una determinata Relying Party. La Recommendation Level 3 del W3C descrive proprio credenziali pubbliche “scoped” alla RP e legate agli autenticatori.
Il browser mette in comunicazione il servizio con l’autenticatore. Quest’ultimo può essere integrato nel computer o nello smartphone oppure essere un dispositivo esterno.
Dopo l’eventuale verifica dell’utente viene creata la credenziale.
Il servizio riceve le informazioni pubbliche necessarie per riconoscerla in futuro, compresi l’identificatore della credenziale e la relativa chiave pubblica. La componente privata rimane invece sotto il controllo dell’autenticatore o del gestore delle passkey.
Quando torniamo successivamente sul servizio, viene generata una nuova richiesta. L’autenticatore usa la chiave privata per produrre una risposta crittografica e il server utilizza la chiave pubblica registrata per verificarla.
La chiave privata non deve essere mostrata all’utente, copiata negli appunti o spedita al sito.
Perché le passkey resistono al phishing
Qui troviamo uno dei vantaggi tecnici più importanti.
Una password non conosce il sito nel quale viene digitata. Se un utente riceve un’e-mail contraffatta e apre una pagina graficamente identica a quella del proprio servizio, può inserire volontariamente username e password nel dominio sbagliato.
Un aggressore può quindi raccogliere quelle informazioni e tentare di riutilizzarle sul servizio autentico.
Con una passkey il protocollo non dipende soltanto dalla capacità dell’utente di riconoscere la pagina corretta.
La credenziale è associata all’identità del servizio per il quale è stata creata. Browser e sistema operativo verificano questo contesto prima di consentirne l’utilizzo.
Google riassume il concetto affermando che le passkey funzionano con il sito o l’applicazione per cui sono state registrate e che il controllo viene effettuato dal browser o dal sistema operativo.
Anche il NIST utilizza WebAuthn come esempio di autenticazione resistente al phishing tramite verifier name binding: l’output dell’autenticatore viene legato crittograficamente all’identità del verificatore.
Questo è molto diverso dai codici OTP che dobbiamo leggere e digitare manualmente. Il NIST precisa che i meccanismi nei quali l’utente inserisce manualmente l’output dell’autenticatore non sono considerati intrinsecamente phishing-resistant, perché un falso verificatore potrebbe intercettare e inoltrare quel valore.
La definizione corretta, però, è resistente al phishing, non “invulnerabile a qualsiasi attacco”.
Impronta, volto e PIN: cosa vede realmente il sito
L’interfaccia può facilmente creare un equivoco.
Premiamo il sensore dell’impronta, guardiamo la fotocamera oppure inseriamo il PIN del computer e veniamo autenticati. È quindi naturale chiedersi se il sito riceva il nostro dato biometrico.
La risposta è no.
La biometria viene utilizzata localmente per consentire l’impiego della credenziale. Il sito non ha bisogno di ricevere l’immagine del volto o l’impronta digitale per eseguire la verifica crittografica.
FIDO Alliance specifica che le informazioni biometriche eventualmente utilizzate non lasciano il dispositivo. Google chiarisce lo stesso punto nella propria documentazione sulle passkey: il materiale biometrico rimane sul dispositivo personale dell’utente.
Lo stesso ragionamento aiuta a capire il ruolo del PIN.
Il PIN del computer o dello smartphone non diventa automaticamente la password dell’account remoto. Serve a verificare localmente che l’utilizzatore possa autorizzare quella credenziale.
Dobbiamo quindi distinguere due operazioni: verificare localmente l’utente e autenticare crittograficamente il dispositivo presso il servizio.
Sono collegate, ma non sono la stessa cosa.
Passkey sincronizzate e passkey legate al dispositivo
Arrivati a questo punto nasce una domanda: dove si trova fisicamente la chiave privata?
La risposta dipende dall’implementazione.
FIDO distingue le synced passkeys, che possono essere rese disponibili su più dispositivi tramite un passkey provider, dalle device-bound passkeys, legate a uno specifico dispositivo o autenticatore.
Questo spiega perché non è sempre corretto dire semplicemente che “la passkey rimane dentro il telefono”.
Un gestore delle credenziali può infatti proteggere e sincronizzare una passkey fra dispositivi appartenenti allo stesso ecosistema o account.
Google Password Manager, per esempio, permette di sincronizzare le passkey nei propri ambienti supportati e dichiara che i segreti vengono protetti con crittografia end-to-end.
La sincronizzazione migliora notevolmente l’usabilità, perché consente di cambiare dispositivo senza dover registrare nuovamente ogni credenziale.
Una credenziale device-bound adotta invece un modello differente: rimane associata allo specifico autenticatore.
Nessuno dei due modelli può essere descritto correttamente soltanto con “meglio” o “peggio”. Cambiano requisiti, praticità, modalità di recupero e livello di assurance richiesto.
Usare una passkey da un altro dispositivo
Non è nemmeno necessario che la credenziale sia sempre sincronizzata sul dispositivo dal quale stiamo effettuando l’accesso.
Immaginiamo di aprire un sito sul computer mentre la passkey è disponibile sul nostro smartphone.
I sistemi compatibili possono consentire un’autenticazione cross-device: il computer presenta, per esempio, un QR code; lo smartphone viene utilizzato per approvare l’accesso e i due dispositivi verificano anche la loro prossimità.
Google documenta esplicitamente questa modalità e il relativo impiego del telefono per autenticarsi su un altro dispositivo.
FIDO descrive il meccanismo cross-device come un’estensione del Client to Authenticator Protocol e specifica l’utilizzo di Bluetooth Low Energy per verificare la prossimità, mentre la sicurezza dell’autenticazione non dipende semplicemente dalle proprietà di sicurezza del Bluetooth.
Anche in questo scenario non dobbiamo conoscere né digitare la chiave privata.
La complessità crittografica rimane nascosta dietro un’operazione relativamente semplice per l’utente.
Se perdiamo il telefono: recupero e limiti delle passkey
L’eliminazione della password non elimina la necessità di pensare al recupero dell’account.
Se una passkey è sincronizzata attraverso un provider, può essere disponibile su altri dispositivi appartenenti allo stesso ambiente.
Se invece è legata a uno specifico autenticatore, può diventare importante aver registrato un secondo metodo di autenticazione o un altro autenticatore.
Ed è proprio qui che non bisogna semplificare troppo il discorso.
Un protocollo di autenticazione può essere molto robusto mentre la procedura di recupero dell’account rimane debole.
Se un servizio consente di aggirare una passkey mediante una procedura di recupero vulnerabile al social engineering, un aggressore potrebbe tentare quella strada anziché attaccare direttamente WebAuthn.
La sicurezza complessiva dipende quindi anche dalla protezione del dispositivo, del passkey provider, dell’account utilizzato per la sincronizzazione e dei meccanismi di recupero.
Esistono inoltre minacce che una passkey non nasce per risolvere.
Un computer profondamente compromesso, un malware capace di agire dentro una sessione già autenticata, il furto dei cookie di sessione o una vulnerabilità dell’applicazione possono spostare l’attacco oltre il momento dell’autenticazione.
Dire che le passkey sono resistenti al phishing non significa quindi attribuire loro proprietà che non hanno.
Significa riconoscere che eliminano uno dei problemi strutturali delle password: un segreto riutilizzabile che l’utente può essere convinto a consegnare al verificatore sbagliato.
Passkey e password: cosa cambia davvero
La differenza fondamentale non è soltanto la comodità.
Una password è qualcosa che l’utente conosce e che deve poter presentare al sistema. Anche se il server la conserva correttamente sotto forma derivata e non in chiaro, l’utente continua ad avere un segreto digitabile.
Questo apre la strada a password deboli, riutilizzo, credential stuffing e phishing.
Con una passkey il server non conserva il segreto necessario per impersonare direttamente l’utente. Conserva invece una chiave pubblica che permette di verificare una prova prodotta dalla chiave privata corrispondente.
FIDO descrive le proprie credenziali proprio come un sistema challenge-response basato su crittografia asimmetrica, progettato per eliminare i segreti sensibili dal server e fornire resistenza al phishing.
È questo il vero cambiamento.
Non abbiamo semplicemente trovato un modo più comodo per conservare una password.
Abbiamo cambiato ciò che viene utilizzato per dimostrare l’identità.
Domande frequenti sulle passkey
Una passkey è una password molto lunga?
No. Utilizza una coppia di chiavi crittografiche e un protocollo challenge-response. La chiave privata non viene digitata né consegnata al server.
Il sito vede la mia impronta digitale?
No. La biometria, quando utilizzata, serve alla verifica locale dell’utente e non viene comunicata al sito.
Una passkey protegge dal phishing?
Il protocollo è progettato per essere phishing-resistant perché lega la credenziale all’identità del servizio. Il NIST cita WebAuthn come esempio di verifier name binding.
Se cambio smartphone perdo tutto?
Non necessariamente. Le passkey sincronizzate possono essere rese disponibili attraverso il relativo provider. Le credenziali device-bound seguono invece un modello differente.
È ancora necessaria l’autenticazione a due fattori?
Dipende dal servizio e dall’implementazione. Una passkey può combinare il possesso dell’autenticatore con una verifica locale dell’utente, ma non è corretto trasformare questa affermazione in una regola universale per qualsiasi servizio.
Conclusioni
Le passkey sono interessanti perché modificano alla radice il modo in cui un servizio può verificare la nostra identità.
La password è un segreto che conosciamo, possiamo copiare, riutilizzare e purtroppo anche consegnare alla persona sbagliata.
Una passkey utilizza invece crittografia a chiave pubblica. Il servizio registra la componente pubblica, mentre l’autenticatore utilizza la corrispondente componente privata per produrre una prova crittografica.
WebAuthn associa inoltre la credenziale alla Relying Party per cui è stata creata. È questa caratteristica, più della semplice comodità del PIN o della biometria, a spiegare la sua resistenza al phishing.
Non significa che account, dispositivi e sessioni diventino invulnerabili. Recupero, sincronizzazione, malware e sicurezza dell’intero ecosistema continuano a essere importanti.
Ma sul problema storico della password — un segreto che può essere copiato e digitato nel posto sbagliato — il cambiamento è sostanziale.
Una passkey non è quindi una password migliore.
È un modo diverso di dimostrare di essere autorizzati ad accedere.