Password vs Passkey: differenze chiave e confronto sulla sicurezza

Password vs Passkey: le password utilizzano segreti condivisi vulnerabili a phishing e violazioni, mentre le passkey utilizzano la crittografia FIDO2, mantenendo le chiavi private sicure sul tuo dispositivo.

Che cosa sono password e passkey?

Considera questo scenario: alle 2:14 del mattino, il tuo analista SOC esamina i log di autenticazione che mostrano centinaia di tentativi di accesso falliti nell’ultima ora. Alle 2:31, uno ha successo utilizzando credenziali rubate da una precedente violazione, e il tuo stack di sicurezza non lo ha mai segnalato.

Questa è la differenza fondamentale tra password e passkey. Le password si basano su un modello di segreto condiviso in cui la stessa credenziale esiste sia sul tuo dispositivo che sul server. Quando gli aggressori violano quel server o effettuano phishing su quella credenziale, hanno tutto ciò che serve per autenticarsi. Le passkey eliminano questa vulnerabilità tramite crittografia asimmetrica. Le chiavi private non lasciano mai il tuo dispositivo e le chiavi pubbliche archiviate sui server sono crittograficamente inutili per gli aggressori.

Secondo il DBIR 2025 che analizza 22.052 incidenti di sicurezza, l’88% delle violazioni ha coinvolto credenziali rubate. Le password creano una vulnerabilità sistemica indipendentemente dai requisiti di complessità, dalle politiche di rotazione o dalla formazione degli utenti.

Le passkey implementano l’architettura del protocollo FIDO2 tramite due standard complementari: la specifica W3C Web Authentication (WebAuthn) per la gestione delle credenziali su browser e piattaforme, e il FIDO Alliance CTAP2 (Client to Authenticator Protocol) per la comunicazione tra applicazioni e autenticatori. Insieme, questi protocolli sostituiscono la trasmissione della password con un’autenticazione a sfida-risposta crittografica vincolata a domini specifici.

Quando registri una passkey, il tuo autenticatore genera una coppia di chiavi pubblica-privata unica per quell’account specifico. La chiave privata rimane protetta nell’hardware security module o secure enclave del dispositivo e non viene mai trasmessa in rete. Solo la chiave pubblica viene registrata sul server. Durante l’autenticazione, il server invia una sfida crittografica che il tuo dispositivo firma con la chiave privata, dimostrando il possesso senza mai esporre la chiave stessa.

Queste differenze architetturali determinano direttamente quali attacchi hanno successo e quali falliscono contro la tua infrastruttura.

Relazione tra password, passkey e cybersecurity

Le passkey affrontano le debolezze di autenticazione che causano la maggior parte delle violazioni. La NIST Special Publication 800-63B richiede autenticazione resistente al phishing per AAL2 e la rende obbligatoria per AAL3, e CISA CPG 2.0 raccomanda esplicitamente le passkey come metodo resistente al phishing. Le password non possono soddisfare nessuno dei due requisiti indipendentemente da lunghezza, complessità o frequenza di rotazione.

I dati lo confermano. Secondo la ricerca DBIR 2025, gli attacchi di credential stuffing hanno rappresentato il 44% di tutto il traffico di autenticazione nei giorni di picco, e l’80% degli account compromessi aveva già subito esposizione di credenziali da altri servizi. Il ransomware è apparso nel 44% delle violazioni, con il riutilizzo delle password come punto di accesso iniziale. L’attacco alla Colonial Pipeline del 2021 lo illustra bene; gli aggressori hanno utilizzato una sola password VPN compromessa per ottenere l’accesso alla rete, con un riscatto di 4,4 milioni di dollari secondo le dichiarazioni DOJ.

Le passkey eliminano questi vettori di attacco. Secondo la FIDO Alliance, il design delle passkey rende le credenziali resistenti a phishing, credential stuffing e data breach su larga scala perché le chiavi pubbliche archiviate sui server non hanno valore di autenticazione senza le chiavi private sui dispositivi degli utenti.

Prima di esaminare in dettaglio i vettori di attacco specifici, la seguente tabella mostra come password e passkey si confrontano sulle dimensioni più rilevanti per i team di sicurezza.

Password vs Passkey a colpo d’occhio

Le differenze tra password e passkey riguardano architettura di sicurezza, esperienza utente, prontezza alla conformità e supporto dell’ecosistema. Questo confronto si basa su ricerche FIDO Alliance, standard NIST e dati DBIR Verizon per quantificare ogni dimensione.

Caratteristica	Password	Passkey
Modello di autenticazione	Segreto condiviso (il server memorizza la credenziale)	Crittografia asimmetrica (il server memorizza solo la chiave pubblica)
Resistenza al phishing	Nessuna; le credenziali vengono trasmesse a qualsiasi dominio	Il binding crittografico al dominio blocca i siti di phishing
Rischio di credential stuffing	Alto; le credenziali riutilizzate funzionano su più servizi	Nessuno; ogni credenziale è unica per servizio
Tasso di successo login	Media 63% (FIDO Alliance Passkey Index)	Media 93% (FIDO Alliance Passkey Index)
Velocità di login	~27,5 secondi in media	~13,6 secondi in media (FIDO Alliance Passkey Index)
Azione richiesta all’utente	Memorizzare e digitare la password, poi completare MFA	Scansione biometrica o PIN del dispositivo
Impatto di una violazione del server	Password hashate esposte ad attacchi offline	Le chiavi pubbliche sono inutili senza le chiavi private
Metodo di recupero	Reset password via email	Passkey sincronizzate, autenticatore di backup o recupero admin
Conformità (NIST AAL2/AAL3)	Non soddisfa i requisiti di resistenza al phishing	Soddisfa i requisiti di resistenza al phishing
Supporto piattaforme	Universale	Ecosistemi Apple, Google, Microsoft; 48% dei primi 100 siti web

Le sezioni seguenti esaminano ciascuna di queste dimensioni in dettaglio, a partire dalle vulnerabilità specifiche delle password che le passkey sono progettate per eliminare.

Vulnerabilità di sicurezza: vettori di attacco alle password

Le password creano quattro principali debolezze che influenzano direttamente la tua postura di sicurezza: vulnerabilità al phishing, esposizione al credential stuffing, intercettazione man-in-the-middle e impatto delle violazioni dei database. NIST SP 800-63B conferma che l’architettura crittografica asimmetrica di FIDO2/WebAuthn consente un’autenticazione resistente al phishing che le password non possono raggiungere indipendentemente dai requisiti di complessità.

• Gli attacchi di phishing restano efficaci contro l’autenticazione basata su password. Secondo la ricerca riassunta nel DBIR Verizon 2025, gli utenti continuano a cliccare su esercitazioni di phishing simulate anche dopo sessioni di formazione. Quando gli utenti inseriscono le password su domini controllati dagli aggressori, quelle credenziali vengono trasmesse in chiaro agli avversari che le testano immediatamente sui tuoi servizi reali. La violazione MGM Resorts del 2023 lo dimostra bene; gli aggressori hanno utilizzato social engineering per bypassare MFA, causando circa 100 milioni di dollari di danni secondo le dichiarazioni SEC.
• Il credential stuffing sfrutta il riutilizzo delle password su larga scala. Il Data Breach Investigations Report 2025 di Verizon conferma che l’80% degli account compromessi aveva già subito esposizione di credenziali da altri servizi. Gli utenti riutilizzano regolarmente le credenziali tra servizi consumer, piattaforme professionali e applicazioni aziendali. Quando un qualsiasi servizio consumer subisce una violazione, gli aggressori testano immediatamente quelle credenziali sugli endpoint di autenticazione aziendali.
• Gli attacchi man-in-the-middle intercettano la trasmissione delle password. Gli attaccanti MITM si posizionano tra utenti e server, utilizzando tecniche come certificati SSL falsi per intercettare i dati in transito. L’autenticazione basata su password richiede la trasmissione di un segreto che prova l’identità, e questa trasmissione crea vulnerabilità indipendentemente dalla cifratura del trasporto.
• I data breach espongono le password archiviate nonostante l’hashing. Il tuo database di autenticazione contiene hash delle password, non password in chiaro. Questa protezione ritarda la compromissione delle credenziali ma non la impedisce. Gli aggressori con accesso al database eseguono attacchi brute-force offline contro le password hashate senza attivare policy di blocco account o rate limiting. Quando il tuo database viene violato, ogni password richiede un reset immediato su tutta la base utenti.

Le passkey eliminano queste vulnerabilità tramite un’architettura crittografica che rende inefficace il furto delle credenziali.

Architettura crittografica delle passkey

Le garanzie di sicurezza offerte dalle passkey dipendono dal funzionamento della crittografia sottostante. A differenza delle password, che si basano sulla segretezza di un valore condiviso, le passkey utilizzano la crittografia a chiave pubblica in cui la prova di autenticazione e il segreto di autenticazione sono oggetti fondamentalmente diversi.

Durante l’autenticazione, il server invia una sfida crittografica all’autenticatore dell’utente tramite l’API WebAuthn. L’autenticatore firma questa sfida utilizzando la chiave privata memorizzata sul dispositivo e l’asserzione firmata viene restituita al server tramite il browser. Il server verifica la firma digitale utilizzando la chiave pubblica precedentemente registrata. Questo processo di sfida-risposta dimostra che l’utente possiede la chiave privata senza mai esporla.

Il binding al dominio fornisce resistenza al phishing. WebAuthn vincola crittograficamente l’autenticazione al dominio di origine specifico in cui è avvenuta la registrazione. Quando gli utenti visitano siti di  phishing che imitano il tuo dominio, l’implementazione WebAuthn del browser blocca le risposte di autenticazione verso l’origine errata. Questa protezione opera a livello di protocollo, non sul giudizio dell’utente. I siti di phishing non possono ricevere risposte di autenticazione valide per il tuo dominio anche se gli utenti sono completamente ingannati dalla somiglianza visiva.

Gli algoritmi crittografici soddisfano le specifiche NIST per implementazioni governative e aziendali. Gli algoritmi supportati includono:

• Varianti ECDSA, RSA ed EdDSA per operazioni di firma
• FIPS 202 (SHA-3) per hashing
• SP 800-108 per derivazione delle chiavi
• SP 800-90a per generazione di numeri casuali

Questi sono definiti nella FIDO Authenticator Allowed Cryptography List, che fa esplicito riferimento agli standard NIST. Le credenziali discoverable basate su questa architettura abilitano l’autenticazione passwordless in cui gli utenti non devono ricordare username e l’integrazione con l’autocompletamento del browser semplifica l’esperienza di login.

Questa base crittografica si traduce in differenze tangibili nel modo in cui password e passkey vengono percepite nell’uso quotidiano.

Esperienza utente: login con password vs passkey

L’autenticazione tramite password richiede agli utenti di ricordare credenziali uniche per ogni servizio, digitarle correttamente e completare ulteriori passaggi MFA come inserire codici SMS o approvare notifiche push. Questo processo multi-step genera attrito misurabile. Secondo il FIDO Alliance Passkey Index, i login basati su password hanno un tasso di successo medio del 63%, il che significa che più di un tentativo su tre fallisce a causa di credenziali dimenticate, errori di digitazione o token MFA scaduti.

L’autenticazione tramite passkey riduce il login a un solo passaggio. Gli utenti si autenticano tramite biometria (Face ID, impronta digitale o Windows Hello) o PIN del dispositivo. La ricerca FIDO Alliance World Passkey Day ha rilevato che le passkey raggiungono un tasso di successo del 93% e una media di 13,6 secondi per accesso rispetto ai 27,5 secondi delle password. Non c’è nulla da ricordare, nulla da digitare e nulla da intercettare. I dati biometrici rimangono sul dispositivo e non vengono mai trasmessi al server, preservando sia la sicurezza che la privacy.

Per le organizzazioni, questo miglioramento UX si traduce direttamente in risparmi operativi. I partecipanti al FIDO Alliance Passkey Index hanno riportato una riduzione dell’81% delle chiamate all’help desk relative all’accesso dopo l’implementazione delle passkey, eliminando uno dei maggiori costi ricorrenti dell’IT support.

Questi benefici UX dipendono da dove effettivamente operano utenti e applicazioni, portando in primo piano la prontezza di piattaforme ed ecosistemi.

Supporto di piattaforme ed ecosistemi

Il supporto alle passkey ha raggiunto un’ampia disponibilità sulle principali piattaforme:

• Apple sincronizza le passkey tramite iCloud Keychain su dispositivi iOS, iPadOS e macOS utilizzando crittografia end-to-end.
• Google gestisce le passkey tramite Google Password Manager su Android 9+ e Chrome, sincronizzando su tutti i dispositivi collegati allo stesso account Google.
• Microsoft integra le passkey tramite Windows Hello su Windows 10+ con supporto in Edge e account Microsoft.

Secondo la FIDO Alliance, il 48% dei primi 100 siti web al mondo ora supporta l’autenticazione tramite passkey, più del doppio rispetto al 2022.

L’autenticazione cross-platform funziona tramite QR code e prossimità Bluetooth, consentendo agli utenti di autenticarsi su un laptop utilizzando una passkey memorizzata sul telefono. Gestori di password di terze parti come 1Password e Bitwarden ora supportano l’archiviazione e la sincronizzazione delle passkey, riducendo la dipendenza da un singolo ecosistema. Il Credential Exchange Protocol (CXP) della FIDO Alliance sta maturando per abilitare il trasferimento sicuro delle passkey tra provider, affrontando il rischio di vendor lock-in.

Il supporto dei browser è completo. Safari, Chrome, Edge e Firefox implementano tutti l’API WebAuthn necessaria per l’autenticazione tramite passkey. Questo significa che le tue applicazioni web possono supportare le passkey senza codice specifico per browser.

Nonostante questo ampio supporto di piattaforma, le passkey introducono compromessi che le organizzazioni devono pianificare prima di un rollout.

Limitazioni e compromessi delle passkey

Nessuna tecnologia di autenticazione è priva di attriti, e comprendere questi vincoli aiuta a costruire una strategia di implementazione realistica.

1. La dipendenza dall’ecosistema resta una criticità. Le passkey sincronizzate sono attualmente legate a gestori di credenziali specifici per piattaforma. Un dipendente che usa Apple iCloud Keychain non può accedere direttamente a quelle passkey da un dispositivo Android. Sebbene l’autenticazione tramite QR code e i gestori di password di terze parti offrano soluzioni alternative, la portabilità cross-ecosistema è ancora in fase di maturazione. Il Credential Exchange Protocol della FIDO Alliance mira a risolvere questo aspetto, ma l’interoperabilità completa non è ancora standard.
2. Account condivisi e di servizio creano complicazioni. Le passkey sono vincolate a dispositivi e biometrici individuali, rendendole difficili da usare per account di team condivisi, account di servizio o terminali kiosk dove più utenti si autenticano sullo stesso dispositivo. Le organizzazioni tipicamente mantengono l’autenticazione basata su password per gli account condivisi, distribuendo le passkey per l’accesso degli utenti individuali.
3. Il recupero senza password richiede nuovi workflow. Quando un utente perde tutti i dispositivi e non ha autenticatore di backup registrato, il recupero dell’account diventa più complesso rispetto a un semplice reset password. Le organizzazioni necessitano di procedure di recupero ben testate, inclusi recupero assistito da amministratore e verifica dell’identità out-of-band.
4. Non tutti i servizi supportano ancora le passkey. Nonostante l’adozione crescente, molte applicazioni legacy, strumenti interni e prodotti SaaS di terze parti non supportano ancora WebAuthn. È probabile che la tua organizzazione mantenga un’autenticazione ibrida, con le passkey a protezione dei principali identity provider e le password che persistono per i sistemi non supportati durante la migrazione.

Queste limitazioni influenzano l’approccio pratico delle aziende al rollout delle passkey, e i dati mostrano che la maggior parte sta procedendo nonostante la complessità.

Implementazione aziendale di password vs passkey

Secondo il FIDO Alliance Enterprise Deployment Survey su 400 dirigenti UK e US di aziende con oltre 500 dipendenti, l’87% delle organizzazioni ha già implementato o sta implementando l’autenticazione tramite passkey per l’accesso dei dipendenti. Molte adottano approcci graduali, affrontando prima l’integrazione infrastrutturale prima del rollout universale. Le organizzazioni hanno documentato una riduzione del 26% nell’uso delle password dopo l’implementazione delle passkey, dimostrando che anche l’adozione parziale offre miglioramenti di sicurezza misurabili mentre si affronta la compatibilità dei sistemi legacy.

La tua piattaforma di identità deve supportare l’API WebAuthn e la gestione del ciclo di vita delle passkey. La maggior parte dei moderni identity provider ora supporta l’autenticazione tramite passkey tramite WebAuthn. L’integrazione avviene a livello di Identity Provider (IdP), dove gli utenti si autenticano tramite passkey prima che vengano emesse asserzioni SAML o token OIDC alle applicazioni federate. Le piattaforme di sicurezza come SentinelOne Singularity Platform dovrebbero integrarsi con il tuo IdP per mantenere la visibilità sugli eventi di autenticazione, correlando i login basati su passkey con l’attività degli endpoint e l’analisi del comportamento utente.

Le tue policy di Mobile Device Management (MDM) e Unified Endpoint Management (UEM) richiedono anch’esse aggiornamenti per supportare autenticatore passkey e attestazione dei dispositivi. La compatibilità con le applicazioni legacy rappresenta la principale barriera all’implementazione. È necessario un inventario completo delle applicazioni per mappare quali sistemi supportano le passkey e quali richiedono soluzioni gateway o la continuazione dell’autenticazione tramite password durante la migrazione.

L’adozione da parte degli utenti determina i risultati di sicurezza. Il Thales/FIDO Alliance State of Passkey Deployment Report per il 2024 identifica la formazione degli utenti come principale sfida di implementazione. Documenta la confusione degli utenti sui concetti di passkey, in particolare sulla sincronizzazione cross-device, e la resistenza al cambiamento delle abitudini consolidate. Le organizzazioni che non promuovono l’adozione rischiano di mantenere le stesse vulnerabilità e costi anche dopo aver implementato le passkey.

Oltre all’implementazione operativa, l’adozione delle passkey deve anche soddisfare i framework di conformità e le architetture Zero Trust che regolano la postura di sicurezza aziendale.

Conformità e allineamento Zero Trust

Le passkey soddisfano i requisiti di autenticazione resistente al phishing che le password non possono raggiungere. La NIST Special Publication 800-63B definisce livelli di assurance di autenticazione in cui AAL2 richiede esplicitamente opzioni resistenti al phishing e AAL3 le rende obbligatorie. Se utilizzi solo password, non puoi soddisfare questi requisiti indipendentemente dalle policy di complessità o dai livelli di autenticazione multi-fattore.

Per le implementazioni aziendali federali, la guida supplementare NIST conferma che le passkey sincronizzate soddisfano i requisiti AAL2. Le chiavi di autenticazione federali devono essere archiviate in infrastrutture di sincronizzazione che abbiano ottenuto la conformità Federal Information Security Modernization Act (FISMA). Il PCI Security Standards Council ha inoltre pubblicato le FAQ 1595 e 1596 che affrontano specificamente le passkey e l’autenticazione FIDO2 per la conformità nel settore dei pagamenti.

Le passkey sono allineate ai principi fondamentali Zero Trust:

• Le chiavi private non lasciano mai il dispositivo autenticatore, prevenendo furto di credenziali e attacchi di replay.
• L’autenticazione è vincolata crittograficamente ai domini verificati, bloccando il phishing tramite la validazione della relying party.
• Ogni sessione richiede una prova crittografica del possesso del dispositivo invece della presentazione di credenziali memorizzate.

Insieme, queste proprietà supportano il mandato Zero Trust “never trust, always verify”.

Per le organizzazioni in giurisdizioni GDPR, sanità o ambienti di conformità SOC 2, le passkey supportano la conformità riducendo l’esposizione dei dati personali e offrendo autenticazione resistente al phishing conforme agli standard NIST AAL2/AAL3. Soddisfare questi requisiti è solo una parte dell’equazione; l’altra è mantenere la visibilità su tutta l’infrastruttura di autenticazione durante la transizione.

Key Takeaways

Le password creano una vulnerabilità sistemica tramite segreti condivisi che gli aggressori rubano tramite phishing, credential stuffing e data breach. Le passkey eliminano questi attacchi tramite  crittografia asimmetrica in cui le chiavi private non lasciano mai i dispositivi degli utenti. 

Con l’88% delle violazioni che coinvolgono credenziali rubate e l’87% delle aziende US/UK con oltre 500 dipendenti che implementano o stanno implementando le passkey, la direzione è chiara. NIST e CISA richiedono esplicitamente autenticazione resistente al phishing che le password non possono offrire indipendentemente dalle policy di complessità.

Domande frequenti

Che cos'è una passkey e in cosa si differenzia da una password?

Una passkey è una credenziale di autenticazione resistente al phishing basata sullo standard FIDO2/WebAuthn. Utilizza la crittografia asimmetrica per generare una coppia di chiavi pubblica-privata unica per ogni account. La chiave privata rimane sul tuo dispositivo e non viene mai trasmessa ai server. 

Una password è un segreto condiviso memorizzato sia sul tuo dispositivo che sul server, rendendola vulnerabile a phishing, credential stuffing e violazioni di database. Le passkey dimostrano l'identità tramite una sfida crittografica invece di trasmettere un segreto riutilizzabile.

Le passkey possono essere oggetto di phishing come le password?

Le passkey utilizzano il binding crittografico del dominio che rende le risposte di autenticazione valide solo per il dominio di origine specifico in cui è avvenuta la registrazione. Quando gli utenti visitano siti di phishing, l'implementazione WebAuthn del browser blocca le risposte di autenticazione impedendo che raggiungano il dominio errato. 

Questa protezione opera a livello di protocollo invece di affidarsi agli utenti per individuare siti fraudolenti. La FIDO Alliance classifica formalmente sia le passkey sincronizzate che quelle vincolate al dispositivo come resistenti al phishing, mentre le password rimangono nella categoria vulnerabile al phishing insieme a OTP via SMS, OTP via email e metodi simili.

Cosa succede se gli utenti perdono i dispositivi con passkey memorizzate?

Le implementazioni di passkey aziendali utilizzano passkey sincronizzate che vengono replicate su tutti i dispositivi connessi allo stesso ecosistema di account, come Apple, Google o Microsoft. Quando gli utenti perdono un dispositivo, le loro passkey rimangono accessibili sugli altri dispositivi autenticati. Le organizzazioni dovrebbero implementare autenticatori di backup e flussi di lavoro di recupero assistiti dall'amministratore per gli scenari in cui gli utenti perdono l'accesso a tutti i dispositivi. 

Per la conformità NIST, le implementazioni federali devono archiviare le chiavi di autenticazione in infrastrutture di sincronizzazione conformi a FISMA come specificato nel Supplemento NIST SP 800-63B sugli Autenticatori Sincronizzabili.

Le passkey funzionano con applicazioni legacy?

Le applicazioni legacy senza supporto WebAuthn non possono accettare direttamente l'autenticazione tramite passkey. Le organizzazioni implementano le passkey a livello di Identity Provider, dove gli utenti si autenticano tramite passkey prima che vengano emesse asserzioni SAML o token OIDC alle applicazioni federate. 

Ciò consente una migrazione graduale; le applicazioni moderne si integrano direttamente con l'autenticazione tramite passkey, mentre le applicazioni legacy ricevono token di federazione standard dopo l'autenticazione IdP basata su passkey.

Quali requisiti di conformità soddisfano le passkey che le password non possono soddisfare?

NIST SP 800-63B richiede autenticazione resistente al phishing per AAL2 e AAL3, che le password non possono soddisfare indipendentemente dalla complessità o dalle politiche di rotazione. CISA raccomanda le passkey come autenticazione predefinita per le infrastrutture critiche tramite metodi resistenti al phishing. 

PCI DSS v4.x affronta le passkey nelle FAQ 1595 e 1596 per la conformità nel settore dei pagamenti. Le implementazioni federali devono soddisfare i requisiti FISMA per l'archiviazione delle chiavi di autenticazione in ambienti di sincronizzazione conformi.