KomuraSoft LLC
Contatti
Menu

Perché le passkey sono sicure — Guida illustrata all'autenticazione che non invia un segreto

· Aggiornato il: · · Passkey, WebAuthn, FIDO2, Sicurezza, Autenticazione, Prevenzione del phishing, Sistemi informativi

La notizia «sono di nuovo uscite le password da un altro grande servizio» non sorprende più nessuno. Si fanno addestramenti al phishing ogni anno, e il numero di chi ci casca non arriva mai a zero. «Non riutilizzate le password, fatele lunghe, il cambio periodico… ormai non serve più» — anche i consigli hanno fatto capriole.

Le passkey, che si sono diffuse rapidamente in questi ultimi anni, sono un metodo di autenticazione che Apple, Google e Microsoft promuovono insieme come risposta a questa situazione.1 Vengono spesso presentate come «comode: si accede con l’impronta o il viso» — ma il punto non è quello. Il vero valore di una passkey è aver spostato il fondamento della sicurezza dall’«attenzione umana» alla «struttura del protocollo».

  • Le password escono perché gli utenti sono disattenti, quindi addestriamoli → gli umani sbagliano sempre
  • Addestriamo le persone a smascherare i siti falsi → si può costruire un sito falso impossibile da smascherare
  • Con una passkey → non c’è un segreto da inviare in partenza, e su un sito falso la firma non si costituisce

Questo articolo, partendo da che cosa è rotto nella password, fissa con i diagrammi perché le passkey sono sicure. Poi risponde di petto alle domande ovvie — «le passkey sincronizzate sono davvero sicure?» e «hanno debolezze?» — e chiude organizzando i punti essenziali della pratica per introdurle in app Web e ambienti Windows.

1. Prima di tutto, la conclusione

Le ragioni per cui le passkey sono sicure si condensano in tre punti.

  1. Sul server non esiste un segreto. Tutto ciò che il server conserva è la chiave pubblica, un’informazione che anche se fuoriesce non si può abusare. Anche se il database esce intero, l’attaccante non ha «materiale per impersonare» da portarsi a casa.2
  2. Il segreto non scorre sulla rete. All’accesso si invia solo una firma su un numero casuale monouso (la challenge). Poiché la chiave privata non esce affatto dall’autenticatore del dispositivo, intercettare o inoltrare ovunque sul percorso non dà un segreto.2
  3. Su un sito falso la firma non si costituisce. La passkey è legata al dominio del sito, e il browser impone il confronto del dominio. Anche se l’utente viene ingannato da un sito falso, la passkey del sito genuino non compare nemmeno tra i candidati, e anche se una firma venisse inoltrata, la verifica la farebbe cadere.3

Questi tre non sono tre stratagemmi indipendenti: sono tutti conseguenze che seguono da un solo cambiamento di progetto, il passaggio dall’autenticazione che condivide e invia un segreto all’autenticazione che dimostra con una firma di possedere un segreto. Li vediamo in ordine.

Il rapporto tra i termini — Passkey, WebAuthn, FIDO2 e CTAP

In questo campo i termini sono tanti, e gli articoli li usano con ambiti diversi, quindi prima si fissano i rapporti. La passkey non è un protocollo nuovo: è un «nome» attaccato a una combinazione di standard esistenti.21

Termine Nome completo Che cosa indica
WebAuthn Web Authentication API (raccomandazione W3C) Lo standard tra browser e sito Web. L’API che con navigator.credentials chiede la creazione della coppia di chiavi e la firma
CTAP Client to Authenticator Protocol (FIDO Alliance) Lo standard tra browser e autenticatore esterno. La parte che parla con chiavi di sicurezza e smartphone su USB, NFC o Bluetooth
FIDO2 — Il nome ombrello del quadro che combina i due sopra. FIDO2 = WebAuthn + CTAP
Passkey — Il nome dato al sottoinsieme delle credenziali FIDO2 che consentono di accedere da sole al posto di una password (credenziali discoverable)

Tabella 1: La passkey è un nome dato sopra il fondamento FIDO2 — non è il nome di uno standard

In altre parole, «supportare le passkey» si traduce, in termini di implementazione, in «implementare WebAuthn». CTAP è uno strato di cui si occupano browser e sistema operativo quando si usa un autenticatore esterno, quindi chi costruisce app Web non lo tocca direttamente.

Mappa della conoscenza di questo articolo

La passkey è una credenziale basata sulla crittografia a chiave pubblica, costruita sugli standard WebAuthn e CTAP (insieme FIDO2): la chiave privata non esce dall’autenticatore, e al server si affida solo la chiave pubblica, che anche se fuoriesce non si può abusare. Poiché la passkey viene creata legata al dominio del sito (RP ID), su un sito falso la firma non si costituisce nemmeno e il phishing viene impedito strutturalmente. Le passkey sincronizzate ottengono resistenza alla perdita in cambio della dipendenza dall’account cloud, mentre quelle vincolate al dispositivo chiudono la chiave nell’hardware. Dopo l’introduzione delle passkey, il fuoco della pratica diventa ridurre i mezzi di fallback coesistenti e rafforzare il flusso di recupero dell’account.

Mappa della conoscenza del perché le passkey sono sicureDiagramma che mostra come le passkey poggino su WebAuthn, FIDO2, CTAP e la crittografia a chiave pubblica, come il legame al dominio tramite RP ID impedisca strutturalmente il phishing, le differenze tra tipo sincronizzato e vincolato al dispositivo e i rispettivi punti di guasto singolo, il posizionamento come MFA resistente al phishing, e i rischi residui (fallback, recupero dell'account, furto di sessione)usausausausausausausausausausausarichiedeusarichiedeprevieneprevieneprevienemitigapuò causarepuò causarepuò causarepuò causarepuò causaresconsigliato perconsigliato perusaconfigurato dasalvato inincompatibile conconsigliato perpuò causareconsigliato perpuò causareconsigliato perpuò causareconsigliato perpuò causaresconsigliato perPasskeyWebAuthnFIDO2Crittografia a chiave pubblicaCTAPAutenticatoreTPMWindows HelloChiave di sicurezzaPasskey vincolata al dispositivoRequisito di contesto sicuro (HTTPS)Challenge (numero casuale monouso)RP ID (identificatore del Relying Party)PhishingPhishing AiTM (man-in-the-middle)Fuga del database delle credenzialiAutenticazione con passwordRiutilizzo delle password (attacco da lista)Dirottamento dell'accountFurto del cookie di sessionePassword monouso (TOTP)MFA resistente al phishingMicrosoft Entra IDPasskey sincronizzataCassaforte delle credenziali della piattaformaNIST AAL3 (livello di garanzia dell'autenticatore 3)Rafforzamento della protezione dell'account di piattaformaAbuso del flusso di recupero dell'accountRafforzamento della verifica dell'identità nel flusso di recuperoMezzo di autenticazione di fallback coesistenteRiduzione pianificata dei mezzi di fallback

Nel diagramma, una linea continua indica una relazione che vale sempre e una linea tratteggiata indica una relazione condizionale (le condizioni sono nella spiegazione di ciascuna relazione nella pagina di dettaglio). L’elenco completo delle relazioni (in totale 38, con evidenza e livello di certezza) e le definizioni dei concetti principali sono raccolti nella pagina di dettaglio della mappa della conoscenza (in giapponese). Dati: JSON-LD / Turtle

2. Che cosa è rotto nell’autenticazione con password

La scorciatoia per capire perché le passkey sono sicure è cogliere le debolezze di una password in termini di «posto». Con l’autenticazione con password, il segreto in sé percorre l’intero tratto a ogni autenticazione.

ServerBrowserUtenteServerBrowserUtenteTiene il segreto (password) in testa[Debolezza 1] Indovinabile, riutilizzata tra siti[Debolezza 2] Si può inserire altrettantofacilmente in un sito falso (indistinguibile a vista)[Debolezza 3] Il segreto scorre sul percorsoTLS lo protegge, ma al capolinea torna in chiaro[Debolezza 4] I segreti (gli hash) di tutti gli utenti si accumulanoSe escono, diventano bersaglio di forza bruta offlineInserisce la passwordInvia la password in séConfronta con l'hash conservato

Figura 1: Nell’autenticazione con password, il segreto in sé esiste su tutto il tratto

Dal punto di vista dell’attaccante, è una struttura con tanti bersagli, facile da colpire.

  • Debolezza 1 (utente): ha solo la forza che si riesce a ricordare, e viene riutilizzata su più siti. Una fuga in un posto si propaga a tutti gli account (attacco da lista di password).
  • Debolezza 2 (l’istante dell’inserimento): se si prepara un sito falso indistinguibile dal vero, l’utente porge da solo il segreto (phishing).
  • Debolezza 3 (percorso): c’è TLS, quindi intercettare il percorso in sé è difficile, ma se si mette in mezzo un «punto di inoltro dall’aspetto legittimo» non serve a nulla (l’AiTM di cui più avanti).
  • Debolezza 4 (server): anche se si conserva in hash, se il database esce si può fare forza bruta offline. Le password deboli si spezzano per prime.

«Allora basta aggiungere un codice monouso (SMS o TOTP)» è l’autenticazione a più fattori tradizionale, ma anche qui la struttura di inviare un segreto condiviso non cambia. TOTP condivide lo stesso seed (segreto) tra server e app di autenticazione, e il codice a 6 cifre generato l’utente lo può comunque inserire in un sito falso. Di fatto, il phishing di tipo AiTM (Adversary-in-the-Middle) in cui un sito falso inoltra in tempo reale al server vero fa passare così com’è la coppia password + codice monouso. Che la CISA (l’agenzia statunitense di cybersecurity) elenchi come «MFA resistente al phishing» solo due cose — il metodo FIDO/WebAuthn e l’autenticazione basata su PKI come le smart card (PIV/CAC) — e posizioni FIDO come gold standard, è per questo.4

In altre parole il problema non è la «forza» della password, ma la struttura in sé di «condividere un segreto e inviarlo a ogni autenticazione».

3. L’identità della passkey — Non si invia il segreto, si dimostra di averlo

La passkey è una credenziale basata sulla crittografia a chiave pubblica, costruita su due standard: WebAuthn del W3C e CTAP della FIDO Alliance (insieme FIDO2).21 Sembra difficile, ma la struttura è semplice.

ServerDispositivo dell'utenteconfronto in localecoppia matematica(il lato che fa la firma)Chiave pubblicaanche se fuoriesce non si può abusareinformazione «solo per verificare»Autenticatore (cassaforte)Windows Hello / Face ID /blocco schermo di Android / chiave di sicurezzaChiave privatanon esce da qui affattoImpronta, viso, PIN= aprono solo la porta della cassafortenemmeno questi escono

Figura 2: L’entità della passkey è una coppia di chiavi per sito. Il lato segreto non esce dal dispositivo, e il server ha solo la chiave pubblica per verificare

  • La chiave privata è la chiave del lato che può fare la firma, viene conservata nell’autenticatore dentro il dispositivo (Windows Hello, Face ID/Touch ID dell’iPhone, blocco schermo di Android, oppure una chiave di sicurezza come YubiKey) e non esce.
  • La chiave pubblica è la chiave del lato che può solo verificare la firma, e questa si affida al server. Calcolare all’indietro la chiave privata dalla pubblica è computazionalmente impossibile, quindi è un’informazione che può anche uscire.
  • I dati biometrici di impronta o viso servono solo per aprire in locale la porta della cassaforte, e nemmeno questi escono dal dispositivo. I dati biometrici non vengono inviati al server.1

Registrazione: si passa «solo» la chiave pubblica

Il flusso quando si registra una passkey su un sito.

AutenticatoreBrowserServer (example.com)AutenticatoreBrowserServer (example.com)Ciò che il server ha ricevuto èsolo «informazione che anche se fuoriesce non si può abusare»Richiesta di registrazione (challenge casuale + informazioni del sito)Crea una chiave per questo sito (example.com)Conferma dell'identità con impronta, viso, PIN (locale)Genera una nuova coppia di chiavila chiave privata resta conservata all'internoChiave pubblica + credential ID (etichetta della chiave)Invia chiave pubblica + credential IDLa conserva come chiave pubblica di questo account

Figura 3: Alla registrazione, ciò che scorre sulla rete e viene conservato sul server è solo la chiave pubblica

L’importante è che in quel momento la coppia di chiavi viene creata legata al dominio del sito (RP ID). Una passkey fatta per example.com si può usare solo sul sito example.com (l’RP ID è per dominio, quindi da una pagina di un sottodominio sotto lo stesso dominio come login.example.com si può usare, ma da un dominio non correlato no). Questo legame è il fondamento della resistenza al phishing di cui più avanti.3

Inoltre, la coppia di chiavi viene creata nuova ogni volta, per ciascun sito. La passkey del sito A e quella del sito B sono matematicamente non correlate, quindi il concetto stesso di «riutilizzo» non esiste, e non diventa nemmeno materiale per incrociare l’utente tra siti.

Autenticazione: si restituisce una firma monouso

Il flusso all’accesso. Si confronti con l’autenticazione con password (figura 1).

AutenticatoreBrowserServer (example.com)AutenticatoreBrowserServer (example.com)Sul percorso scorre solo una firma monousoanche se la si ruba, alla challenge successiva non serveRichiesta di accesso (challenge casuale monouso)Richiesta di firma verso example.comConferma dell'identità con impronta, viso, PIN (locale)Crea la firma con la chiave privataIncorpora challenge + origine + hash dell'RP IDFirma (non è la chiave privata in sé)Invia la firmaVerifica la firma con la chiave pubblica conservataconferma anche challenge, origine e RP ID

Figura 4: Anche all’autenticazione il segreto non si sposta. Ciò che scorre è solo un «documento di prova monouso»

Il server ogni volta pone un numero casuale nuovo (la challenge), e l’autenticatore firma su «quella challenge + l’origine che il browser sta vedendo ora + l’hash dell’RP ID». Il server verifica la firma con la chiave pubblica conservata, e conferma che la challenge è quella che ha posto lui, e che origine e RP ID sono del suo sito.5

Come conseguenza di questo progetto, due delle tre ragioni dell’inizio sono già costituite.

  • Sul server non c’è un segreto: ciò che è conservato è solo la chiave pubblica. Anche se esce, l’attaccante non può fare una firma, quindi non può «portarsela a casa e spezzarla» come un hash di password.
  • Il segreto non scorre: anche se si ruba la firma sul percorso, la challenge è monouso quindi non si può riusare (replay).

Resta la terza, «su un sito falso la firma non si costituisce», che è il punto di vendita più grande della passkey. La vediamo in una sezione a parte.

4. Perché il phishing non si costituisce «strutturalmente»

Il phishing contro la password ha successo perché si può inserire il segreto vero in un sito falso. Per un umano distinguere example.com e examp1e.com (soprattutto se è stanco) non è facile, ma il campo di inserimento della password funziona allo stesso modo su entrambi i siti.

Con le passkey, questo confronto lo fa il browser, in modo meccanico, non l’umano. Per specifica WebAuthn, il browser può chiamare l’autenticatore solo se il «dominio dell’origine ora visualizzata» e l’«RP ID della passkey» corrispondono.3 Si mette in un diagramma che cosa succede nel momento in cui si accede a un sito falso.

Server vero (example.com)Sito falso (examp1e.com)proxy AiTM che inoltra al veroBrowserUtenteServer vero (example.com)Sito falso (examp1e.com)proxy AiTM che inoltra al veroBrowserUtenteAnche se con qualche metodo si creasse una firma,nella firma è incorporato examp1e.com, quindila verifica del server vero la fa cadere per forzaAccede a una schermata di accesso identica a vista(dietro) avvia il trattamento di accesso veroChallengeInoltra la challenge e chiede la firmaL'origine ora è examp1e.comla passkey per example.com non si può mettere tra i candidatiLa firma non viene creata (l'utente non ha modo di farsi ingannare)

Figura 5: Il phishing di tipo AiTM fa passare password + codice monouso, ma con le passkey non si costituisce già alla fase della firma

Si noti che la difesa è doppia.

  1. Non compare tra i candidati: il browser elenca solo le passkey dell’RP ID corrispondente all’origine. Su un dominio falso la passkey del sito vero non compare come opzione, quindi l’utente non può nemmeno «usarla per sbaglio».
  2. La firma non passa: nell’oggetto della firma sono compresi l’origine che il browser ha confermato e l’hash dell’RP ID. Il server vero li confronta in verifica, quindi una firma fatta su un’altra origine viene per forza rifiutata.5

La difesa dal phishing delle password dipendeva dallo sforzo umano «l’utente guarda bene l’URL». Con le passkey l’utente non deve proprio smascherare il sito falso. Questo è il significato esatto della parola «resistente al phishing (phishing-resistant)», ed è la ragione per cui CISA e NIST (l’istituto nazionale di standard statunitense) trattano in modo speciale il metodo FIDO/WebAuthn.46

Il contenuto fin qui, organizzato per tecnica di attacco.

Attacco Password Password+TOTP Passkey
Indovinare / forza bruta ✗ Debole △ Il codice ferma, ma la password di base resta debole ○ Non esiste un bersaglio da indovinare
Riutilizzo (attacco da lista) ✗ Una fuga in un posto si propaga a tutto △ Si sfalda dai siti senza codice ○ Chiave indipendente per sito
Fuga del DB del server ✗ Forza bruta offline sull’hash ✗ Esce anche il seed TOTP (segreto condiviso) ○ C’è solo la chiave pubblica
Phishing classico (far inserire su un sito falso) ✗ Si può inserire ✗ Si può inserire anche il codice ○ Non compare tra i candidati, e la firma non passa
AiTM (inoltro in tempo reale) ✗ Viene inoltrata così com’è ✗ Viene inoltrata anche col codice ○ Per il confronto dell’origine la firma non si costituisce
Replay (riuso della comunicazione) ✗ La stessa password vale quante volte si vuole △ Un codice intercettato prima che lo usi l’interessato vale (la riammissione di un codice già usato, in un’implementazione corretta, viene rifiutata) ○ La challenge è ogni volta monouso

Tabella 2: Confronto di resistenza per tecnica di attacco. I «○» della passkey derivano tutti dalla struttura, non dall’operatività o dall’attenzione

5. Le «passkey che si sincronizzano» sono sicure?

A leggere la spiegazione fin qui, sorge di certo questa domanda. «Avete detto che la chiave privata non esce dal dispositivo, allora perché una passkey fatta sull’iPhone si può usare anche sull’iPad?» — È una buona domanda, e la risposta è «le passkey sono di due tipi».

Prima la conclusione in una tabella di consultazione rapida. Questa sezione e la successiva, pensatele come la spiegazione del perché ciascuna riga di questa tabella è così.

Aspetto Passkey sincronizzata Passkey vincolata al dispositivo
Esempi rappresentativi iCloud Keychain, Google Password Manager, gestori di password come 1Password Chiavi di sicurezza (YubiKey ecc.), Windows Hello, passkey in Microsoft Authenticator
Dove sta la chiave privata Cassaforte delle credenziali della piattaforma. Viene replicata in forma cifrata end-to-end tra i dispositivi dello stesso account Dentro l’hardware dell’autenticatore. Non esce da TPM o secure element
In caso di perdita o cambio di modello Accedendo allo stesso Apple ID/account Google si ripristina sul dispositivo nuovo La passkey di quell’autenticatore si perde. La premessa è registrare più autenticatore di riserva
Punto di guasto singolo L’account cloud della piattaforma Il dispositivo fisico in sé
Adatto o no alla gestione aziendale La chiave entra nell’account cloud personale, quindi dal lato organizzazione è difficile cogliere dove sta e revocarla in blocco. Va per BYOD e piccola scala L’amministratore può distribuire e revocare, e il posto della chiave è chiaro. Va per ambienti con regolamenti severi
Conformità AAL del NIST Se soddisfa i requisiti, AAL2. Poiché la chiave privata è esportabile, non si può usare per AAL36 Un autenticatore protetto in hardware da cui la chiave non si estrae può corrispondere anche ai requisiti che AAL3 chiede6

Tabella 3: Tabella di consultazione rapida tra tipo sincronizzato e vincolato al dispositivo. Quale scegliere lo decide se si prende «la forza contro la perdita» o «il poter gestire dove sta la chiave»

Passkey vincolata al dispositivoChiave di sicurezza (YubiKey ecc.) /Windows Hello /Microsoft Authenticator (Entra ID)La chiave privata non esce fisicamenteda quell'hardware (protetta da TPM ecc.)Vantaggio: il posto della chiave è uno e chiaroAttenzione: per la perdita è obbligatorio registrarne più d'unaPasskey sincronizzata (default per i consumatori)iCloud Keychain /Google Password Manager /gestori di password come 1PasswordSi sincronizza tra i dispositivi dello stesso accountcon cifratura end-to-endnemmeno il gestore può leggere il contenutoVantaggio: forte al cambio di modello e alla perditaAttenzione: serve la difesa dell'account cloud in sé

Figura 6: Tipo sincronizzato e vincolato al dispositivo. In entrambi «non si invia la chiave privata al server» è uguale; cambia il baricentro del modo di proteggere

Le passkey sincronizzate sono quelle in cui iCloud Keychain o Google Password Manager sincronizzano la chiave privata tra i dispositivi dello stesso account. L’importante qui è che la sincronizzazione è cifrata end-to-end. Sia Apple sia Google dichiarano esplicitamente che le passkey vengono cifrate sul dispositivo e poi sincronizzate, e che il gestore stesso non può leggere il contenuto.78 In altre parole il principio «la chiave privata non esce dal dispositivo» si allenta, in modo preciso, in «la chiave privata non esce dal dispositivo in chiaro», e in cambio si ottiene resistenza al cambio di modello e alla perdita.

Come questo allentamento cambia il modello di minaccia va messo in parole chiare. Il posto da proteggere si concentra da «il server di ciascun sito» a «un solo account cloud». Resta forte come prima alle fughe dei DB dei siti e al phishing; stavolta il dirottamento dell’Apple ID/account Google in sé diventa il punto di guasto singolo. Proprio per questo, sull’account di piattaforma a cui si affidano le passkey, la premessa grande è mettere la protezione più forte (blocco schermo robusto, ordine dei mezzi di recupero, se possibile una chiave di sicurezza fisica). Anche il NIST ad aprile 2024 ha uscito un supplemento a NIST SP 800-63B (Supplement 1: Incorporating Syncable Authenticators Into NIST SP 800-63B) e ha posizionato formalmente che questa passkey sincronizzata (syncable authenticator), se soddisfa i requisiti, può soddisfare l’AAL2 (Authenticator Assurance Level 2, livello di garanzia dell’autenticatore 2) dei criteri governativi. Tuttavia, poiché la chiave privata può essere esportata, per AAL3, che chiede un ambiente isolato in hardware, è detto di non usare il tipo sincronizzato.6

Le passkey vincolate al dispositivo sono il tipo in cui la chiave privata non esce dall’hardware. Tipica è una chiave di sicurezza come YubiKey, e in ambito aziendale anche le passkey di Microsoft Entra ID (quelle create in Microsoft Authenticator) sono vincolate al dispositivo.9 Anche Windows Hello di Windows, se c’è un TPM, protegge la chiave privata sotto il TPM. Questo meccanismo di «cassaforte hardware che non fa uscire la chiave» poggia sullo stesso fondamento spiegato in dettaglio nell’articolo sul TPM.

Inoltre, magari vi è capitato di meravigliarvi di dover leggere un QR code quando «si accede al browser del PC con la passkey dello smartphone». Quello non è un semplice passaggio di schermata: è un metodo ibrido (autenticazione cross-device di FIDO) che conferma con Bluetooth la vicinanza fisica di smartphone e PC. Un attacco in cui un attaccante lontano fa approvare a un altro, via QR code, l’accesso al proprio PC, lo si spezza con la conferma di vicinanza.1

6. Non è un proiettile d’argento — Le debolezze non «spariscono», si «spostano»

Fin qui si è spiegata la forza delle passkey, ma per onestà: la passkey non fa sparire gli attacchi, è una tecnica che spinge l’attaccante verso posti più deboli. Quando il portone dell’autenticazione si irrigidisce, dove gira l’attaccante lo si mette in un diagramma.

AttaccanteL'autenticazione in séfirma sulla challenge[Dura]Flusso di recupero dell'accountsi dichiara «ho perso la passkey» esi fa reimpostare via SMS o mail,registrando la passkey dell'attaccanteFallback coesistentese restano password e accesso SMSl'anello più debole è lìAccount cloudse è di tipo sincronizzato Apple ID /account Google è il punto di guasto singoloSessionese si ruba il cookie dopo l'accessoil metodo di autenticazione non conta

Figura 7: Quando il portone (l’autenticazione) si irrigidisce, l’attacco si sposta su flusso di recupero, mezzi coesistenti, account cloud e sessione

I rischi residui da tenere presenti in pratica sono quattro.

  1. Il fallback coesistente diventa l’anello più debole. Se si è solo reso «anche» usabile la passkey e restano password o accesso SMS, l’attaccante usa quelli. La resistenza al phishing, vista sull’account intero, è limitata dal livello del mezzo di accesso più debole. Il cuore dell’introduzione non è aggiungere la passkey, è la riduzione e l’abolizione pianificate del fallback.
  2. Il flusso di recupero diventa una nuova superficie di attacco. È il trucco di fingere «ho perso il dispositivo», portare il discorso a una reimpostazione via sportello di supporto o mail, e farsi registrare la passkey dell’attaccante. Di fatto, l’ingegneria sociale che inganna l’help desk per aggirare un’autenticazione solida è un mezzo consueto delle violazioni su larga scala. Avendo irrigidito l’autenticazione, si pone come progettare la verifica dell’identità nel flusso di recupero.
  3. Nel tipo sincronizzato l’account cloud è il punto di guasto singolo. Come nella sezione precedente. Servono la difesa dell’account a cui si affidano le passkey e, per l’uso in organizzazione, la decisione di policy su «verso quale piattaforma si consente la sincronizzazione».
  4. Il furto di sessione non si previene. La passkey protegge solo l’istante dell’accesso; se dopo l’accesso il cookie di sessione viene rubato da malware o XSS, il metodo di autenticazione non conta. Resta il lavoro di un altro strato: durata dei token, binding, gestione della salute del dispositivo.

Queste non sono un discorso del tipo «allora lasciamo stare le passkey». È il discorso ovvio che anche se si mette la serratura nuova al portone, chiudere le finestre è un altro lavoro. Anzi, poiché il posto della debolezza diventa chiaro, si possono concentrare le risorse di difesa sul flusso di recupero e sulla gestione della sessione.

7. Introduzione in pratica — API WebAuthn e ambiente Windows

Infine, i punti da tenere dal lato di chi introduce.

Mettere il login con passkey sul proprio servizio Web

Dal lato browser sono solo due funzioni dell’API WebAuthn. La registrazione chiama navigator.credentials.create(), l’autenticazione navigator.credentials.get().

// Registrazione (lato browser)
const credential = await navigator.credentials.create({
  publicKey: {
    challenge: challengeFromServer,   // numero casuale monouso generato dal server
    rp: { id: "example.com", name: "Example" },
    user: { id: userIdBytes, name: "taro@example.com", displayName: "Taro" },
    pubKeyCredParams: [{ type: "public-key", alg: -7 }],  // ES256
    authenticatorSelection: {
      residentKey: "required",        // farne una credenziale discoverable (= passkey)
      userVerification: "required",   // rendere obbligatoria la verifica dell'identità con biometria/PIN
    },
  },
});
// Prendere la chiave pubblica da credential.response, e il credential ID da
// credential.id / credential.rawId al livello superiore. Verificare sul server
// la risposta di registrazione (challenge, origin, RP ID) allo stesso modo
// che in autenticazione, poi conservarla

Il significato dei parametri principali è il seguente.

Parametro Ruolo Attenzione in implementazione
challenge Numero casuale monouso che il server genera ogni volta Usare un numero casuale crittografico non indovinabile. Dal lato server verificare che sia «uno non usato, emesso da sé» e consumarlo
rp.id Dominio a cui legare la credenziale (RP ID) Se si omette, diventa il dominio effettivo dell’origine chiamante. Si può specificare solo nell’ambito dei domini registrabili, come specificare example.com da login.example.com
user.id Identificatore utente interno al server (user handle) Valore opaco di al massimo 64 byte. Non metterci così com’è informazioni che identificano la persona, come un indirizzo mail o un nome utente2
user.name / user.displayName Stringhe mostrate nell’interfaccia dell’autenticatore o del browser, perché l’utente scelga l’account Solo per la visualizzazione. Il server non deve fidarsi di questo valore per identificare l’account
pubKeyCredParams Elenca in ordine di preferenza gli algoritmi di chiave pubblica accettati Elencare anche -257 (RS256) oltre a -7 (ES256) allarga la gamma di autenticatore accettati
authenticatorSelection Le proprietà chieste all’autenticatore Con residentKey: "required" diventa una passkey (credenziale discoverable); con userVerification: "required" la verifica dell’identità con biometria o PIN diventa obbligatoria

Tabella 4: I parametri principali di navigator.credentials.create()

Nota sull’ambiente di verifica: l’API WebAuthn è esposta solo in un contesto sicuro, quindi su una pagina servita in http:// nudo la chiamata a navigator.credentials fallisce. L’eccezione è http://localhost (e 127.0.0.1), trattati come origini affidabili, quindi sulla macchina di sviluppo si può provare così com’è senza passare a HTTPS. Tuttavia l’RP ID deve essere il dominio effettivo dell’origine (o un suo dominio padre), quindi una passkey fatta su localhost non si può usare sul dominio di produzione. Anche senza un autenticatore a portata di mano, abilitando l’autenticatore virtuale nella scheda «WebAuthn» degli strumenti per sviluppatori di Chrome si può far girare dall’inizio alla fine dalla registrazione all’autenticazione.

// Autenticazione (lato browser)
const assertion = await navigator.credentials.get({
  publicKey: {
    challenge: challengeFromServer,
    rpId: "example.com",
    userVerification: "required",
  },
  // Offre la passkey come suggerimento di compilazione automatica nel campo di accesso.
  // Verificare prima il supporto con
  // PublicKeyCredential.isConditionalMediationAvailable(), e sui browser
  // non supportati ripiegare su una chiamata normale senza mediation
  mediation: "conditional",
  // (Richiede autocomplete="username webauthn" sull'<input> di destinazione)
});
// Verificare sul server la firma in assertion.response

Il corpo è la verifica dal lato server. Come minimo, si faccia sempre quanto segue.5

  • Confronto della challenge: è una challenge non usata, emessa da sé? La si tratta come monouso (difesa dal replay)? Inoltre, conservarla legata alla sessione del browser (il tentativo di accesso) al momento dell’emissione, e consentirne il consumo solo a una risposta da quella stessa sessione. Se questo è lasco, nasce lo spazio perché un attaccante faccia arrivare, tramite il browser della vittima, una firma su una challenge destinata a lui, e faccia accedere la vittima all’account dell’attaccante (login CSRF).
  • Confronto dell’origine: origin in clientDataJSON è l’origine legittima del proprio sito (il perno della difesa dal phishing).
  • Confronto dell’hash dell’RP ID: rpIdHash in authenticatorData coincide con lo SHA-256 dell’RP ID del proprio sito.
  • Conferma del tipo di cerimonia e dei flag: type in clientDataJSON è webauthn.get per l’autenticazione, webauthn.create per la registrazione. Il flag UP (user present) in authenticatorData è alzato. Se si è chiesta la verifica dell’utente (UV), è alzato anche il flag UV.
  • Verifica della firma: la firma si verifica correttamente con la chiave pubblica conservata alla registrazione.
  • Legame con l’account: si tira il credential ID presentato (e lo userHandle) nel proprio database, e si emette la sessione al proprietario di quella credenziale. Fidarsi senza condizioni di un nome utente inserito a parte apre un buco che, con una firma corretta, fa accedere come un altro.
  • Conservazione e confronto del contatore di firma: si conserva per credenziale il signCount di authenticatorData, e si conferma che il valore successivo è maggiore del precedente. Un valore inferiore o uguale al precedente (parità compresa) si tratta come segno di un autenticatore clonato. Tuttavia molte implementazioni di passkey sincronizzate restituiscono sempre 0, quindi si consente come eccezione solo lo 0 contro 0.

Scrivere questa verifica a mano è origine di incidenti, quindi si usi una libreria con un curriculum (in .NET fido2-net-lib, in Node.js SimpleWebAuthn ecc.). I dettagli della specifica (parse CBOR, accordo sugli algoritmi, gestione della challenge) si lasciano alla libreria; concentrarsi sulla conservazione e sulla revoca delle challenge, sull’interfaccia di gestione di più passkey, sulla progettazione del flusso di recupero è la giusta distribuzione delle forze.

In ambienti Windows e sistemi interni

Dal lato dei lettori di questo sito — «chi ha in carico i sistemi aziendali Windows» — bastano questi tre punti.

  • Il client Windows è già pronto. Windows 11, con Windows Hello come autenticatore, supporta creazione, uso e gestione delle passkey (Impostazioni > Account > Passkey), e la chiave privata, se c’è un TPM, è protetta in hardware.10 WebAuthn via browser (Edge/Chrome) gira anche su Windows 10.
  • In un ambiente Entra ID si attiva «passkey = metodo di autenticazione FIDO2». Microsoft Entra ID supporta le chiavi di sicurezza e le passkey nell’app Microsoft Authenticator (vincolate al dispositivo), e se con la forza di autenticazione di Accesso condizionale si chiede «MFA resistente al phishing», l’accesso alle risorse bersaglio si può limitare a passkey e simili.9 Il passaggio dal mondo di NTLM e dei criteri di scadenza delle password non va in un salto, quindi, in parallelo all’inventario dell’infrastruttura di autenticazione trattato nell’articolo su NTLM e Kerberos, la pratica standard è obbligare prima gli account amministratore alla MFA resistente al phishing.
  • Anche nelle app Web interne il beneficio è lo stesso. Tuttavia HTTPS è premessa. L’API WebAuthn gira solo in un contesto sicuro, quindi anche in un’app intranet (salvo localhost in sviluppo) vengono prima la messa in HTTPS e l’ordine di un nome di dominio interno usabile come RP ID. Fatto quello, l’RP ID funziona anche contro un dominio interno. Nel senso di chiudere con i foglietti delle password, non è raro che l’effetto si veda prima in interno che su un servizio rivolto all’esterno.

8. Conclusione

  • La debolezza della password non è la forza, è la struttura di «condividere un segreto e inviarlo a ogni autenticazione». Poiché il segreto esiste in utente, campo di input, percorso e server, i bersagli di attacco sono tanti. Anche aggiungendo un codice monouso, al phishing di tipo AiTM si viene inoltrati e si perde.
  • La passkey è una coppia di chiavi della crittografia a chiave pubblica per sito: al server si passa solo la chiave pubblica che anche se fuoriesce non si può abusare, e all’accesso si invia solo la firma su una challenge monouso. Sul server non c’è un segreto, e sul percorso non scorre un segreto.
  • Nella firma vengono cotti l’origine e l’RP ID che il browser ha confermato, quindi su un sito falso la passkey del vero non compare tra i candidati, e anche inoltrata cade in verifica. Che l’utente non debba smascherare il sito falso è l’identità della «resistenza al phishing», e il fondamento della difesa si è spostato dall’attenzione umana alla struttura del protocollo.
  • Le passkey sincronizzate si sincronizzano con cifratura end-to-end e sono forti al cambio di modello e alla perdita. In cambio il posto da proteggere si concentra sull’account cloud, quindi la difesa dell’Apple ID/account Google in sé diventa la premessa grande. In azienda si può scegliere anche il tipo vincolato al dispositivo (chiave di sicurezza, passkey Authenticator di Entra ID).
  • La passkey non fa sparire gli attacchi, li spinge verso posti deboli. Password coesistenti, flusso di recupero dell’account, furto di sessione restano superfici di attacco, e il cuore dell’introduzione è la riduzione pianificata del fallback e il rafforzamento del flusso di recupero.
  • L’implementazione è le due funzioni create / get dell’API WebAuthn + la verifica del server. La verifica non si scrive da sé: si lascia a una libreria con un curriculum, e si dedica forza a gestione della challenge, interfaccia di più passkey, progettazione del recupero.

Articoli correlati

Aree di consulenza correlate

KomuraSoft LLC si occupa di Custom Software Development che include il supporto all’implementazione del login con passkey/WebAuthn nei sistemi Web interni, la progettazione della distribuzione di MFA resistente al phishing in ambienti Entra ID, e l’incorporazione dell’autenticazione in app aziendali Windows come WinForms/WPF.

Riferimenti

  1. FIDO Alliance, Passkeys e How FIDO Works. Sul fatto che le passkey sono credenziali FIDO che sostituiscono la password; sul fatto che i dati biometrici non vengono trasmessi dal dispositivo e servono solo al confronto locale; sul fatto che a maggio 2022 Apple, Google e Microsoft hanno dichiarato insieme l’ampliamento del supporto al passwordless basato sugli standard FIDO; sul fatto che nell’uso tra dispositivi (cross-device) si usa un metodo ibrido con QR code e conferma di vicinanza via Bluetooth. ↩ ↩2 ↩3 ↩4 ↩5

  2. W3C, Web Authentication: An API for accessing Public Key Credentials Level 2 (raccomandazione W3C). Sul fatto che WebAuthn è un’API per creare e usare credenziali basate sulla crittografia a chiave pubblica; sul fatto che la chiave privata della credenziale è tenuta dall’autenticatore e sul server (Relying Party) si registrano solo chiave pubblica e credential ID; sul fatto che l’autenticazione avviene tramite una firma (asserzione) su una challenge inviata dal server; e sugli obiettivi di progetto di ambito e protezione della credenziale. Il testo del corpo fa riferimento anche al fatto che l’API è esposta solo in un contesto sicuro, al fatto che l’RP ID se omesso diventa il dominio effettivo dell’origine chiamante, e al fatto che lo user handle (user.id) è un valore opaco di al massimo 64 byte e non dovrebbe includere informazioni che identificano la persona come un nome utente o un indirizzo mail (§14.6.1 User Handle Contents). ↩ ↩2 ↩3 ↩4 ↩5

  3. W3C, Web Authentication Level 2 — §5.1.3 Create / RP ID validation, §13.4.9 Regarding phishing. Sul fatto che le credenziali a chiave pubblica sono in ambito dell’RP ID (identificatore del Relying Party = dominio); sul fatto che il browser (client) verifica la corrispondenza tra il dominio registrabile dell’origine chiamante e l’RP ID e, se non corrisponde, rifiuta creazione e uso della credenziale; sul fatto che da un’origine falsa non si può accedere alla credenziale di un altro sito, e che WebAuthn ha resistenza agli attacchi di phishing compresi quelli di tipo man-in-the-middle. ↩ ↩2 ↩3

  4. CISA, Implementing Phishing-Resistant MFA (foglio informativo dell’ottobre 2022). Sul fatto che l’MFA che usa SMS, voce, notifiche push o OTP è vulnerabile a phishing, attacchi AiTM (inoltro) e attacchi di fatica MFA; sul fatto che come metodi resistenti al phishing sono elencati l’autenticazione FIDO/WebAuthn e l’autenticazione basata su PKI (smart card ecc.), e che l’autenticazione FIDO/WebAuthn è posizionata come gold standard; sul fatto che le organizzazioni dovrebbero migrare prima gli account ad alto rischio verso l’MFA resistente al phishing. ↩ ↩2

  5. W3C, Web Authentication Level 2 — §7.2 Verifying an Authentication Assertion. Sulla procedura di verifica dal lato server che prevede la verifica di type, challenge (coincidenza con quella emessa da sé) e origin in clientDataJSON; la verifica che rpIdHash in authenticatorData coincida con l’hash SHA-256 dell’RP ID atteso; la conferma dei flag User Present / User Verified; e la verifica della firma con la chiave pubblica conservata. ↩ ↩2 ↩3

  6. NIST, Incorporating Syncable Authenticators Into NIST SP 800-63B (supplemento dell’aprile 2024, integrato in SP 800-63B quarta edizione). Sul fatto che un autenticatore sincronizzabile (passkey sincronizzata) può soddisfare AAL2 se la chiave privata è conservata e replicata in un fabric di sincronizzazione in una forma che soddisfa i requisiti; sul fatto che gli autenticatore crittografici AAL3 richiedono un ambiente protetto e isolato in hardware, quindi un autenticatore sincronizzabile la cui chiave privata è esportabile non si usa per AAL3; sul fatto che un metodo che fa la verifica dell’origine, come WebAuthn, è classificato come avente resistenza all’impersonazione del verificatore (resistenza al phishing). Il PDF originale è NIST SP 800-63B Supplement 1. ↩ ↩2 ↩3 ↩4

  7. Supporto Apple, Informazioni sulla sicurezza delle passkey. Sul fatto che le passkey si sincronizzano con iCloud Keychain; sul fatto che iCloud Keychain è cifrato end-to-end e nemmeno Apple può leggerlo; sul fatto che la sincronizzazione è protetta da una chiave sul dispositivo dell’utente e che è previsto un ripristino via escrow con limite di frequenza. ↩

  8. Google, La sicurezza delle passkey in Google Password Manager. Sul fatto che la chiave privata della passkey viene cifrata sul dispositivo e poi sincronizzata; sul fatto che per la cifratura end-to-end nemmeno Google può accedere al contenuto della chiave privata; sul fatto che per il ripristino è richiesta una protezione basata sul blocco schermo del dispositivo e simili. ↩

  9. Microsoft Learn, Enable passkey (FIDO2) authentication in Microsoft Entra ID. Sul fatto che Entra ID supporta l’autenticazione passwordless resistente al phishing tramite chiavi di sicurezza FIDO2 e passkey di Microsoft Authenticator (vincolate al dispositivo); sul fatto che si può attivare con il criterio dei metodi di autenticazione e richiedere con la forza di autenticazione di Accesso condizionale (MFA resistente al phishing). ↩ ↩2

  10. Microsoft Learn, Passkey support on Windows. Sul fatto che Windows 11 supporta creazione e uso delle passkey tramite Windows Hello; sul fatto che le passkey salvate si gestiscono da Impostazioni > Account > Passkey; sul fatto che le credenziali di Windows Hello, in un ambiente in cui è disponibile un TPM, sono protette in hardware; sul fatto che le passkey su un dispositivo mobile si possono usare via QR code. ↩

Articoli correlati

Articoli recenti con gli stessi tag per approfondire argomenti vicini.

Argomenti correlati

Queste pagine collocano l’argomento in un contesto più ampio di servizi e decisioni.

Domande frequenti

Domande che ricorrono nelle consulenze sull’argomento dell’articolo.

Qual è la differenza fondamentale tra passkey e password?
La password è un meccanismo in cui utente e server condividono lo stesso segreto e inviano quel segreto a ogni accesso. Poiché il segreto esiste ovunque — nella testa dell'utente, nel campo di input, sul percorso, nel database del server — tutti quei posti diventano bersaglio di attacco. La passkey usa una coppia di chiavi della crittografia a chiave pubblica, e la chiave privata non viene mai inviata al server. Con una passkey vincolata al dispositivo la chiave privata non esce affatto dall'autenticatore; anche con una passkey sincronizzata esce dal dispositivo solo in forma cifrata end-to-end. Tutto ciò che il server conserva è la chiave pubblica — un'informazione che anche se fuoriesce non si può abusare — e all'accesso si invia solo una firma su una challenge monouso. In altre parole, il segreto condiviso che era la debolezza di fondo della password semplicemente non esiste. In più, poiché una coppia di chiavi viene creata a parte per ciascun sito, l'idea stessa del riutilizzo non si applica.
I dati biometrici (impronta, viso) vengono inviati al server?
No. I dati di impronta o viso servono solo per un confronto locale dentro il dispositivo — per aprire la porta della cassaforte che tiene la chiave privata — e, per progetto FIDO, i dati biometrici non vengono mai trasmessi fuori dal dispositivo. Tutto ciò che il server riceve è una firma con il flag che la verifica dell'identità (user verification) è avvenuta; non contiene nulla dell'impronta in sé, né tantomeno un vettore di caratteristiche biometriche derivato. Dove la biometria non si può usare, può sostituire un PIN e, come il PIN di Windows Hello, anche questo PIN viene confrontato solo in locale sul dispositivo: la differenza decisiva rispetto a una password è che non viaggia sulla rete.
Perché le passkey sono resistenti al phishing?
Perché, per progetto, l'utente non deve proprio smascherare un sito falso. Una passkey viene creata legata al dominio del sito (il suo RP ID), e il browser offre solo le passkey che corrispondono al dominio del sito attualmente visualizzato. Anche se si visita un dominio falso identico a quello vero, la passkey del sito genuino semplicemente non compare come opzione, quindi l'utente non ha modo di farsi ingannare. In più, nella firma sono cotti l'origine che il browser ha confermato e un hash dell'RP ID, quindi anche se la firma venisse inoltrata, la verifica sul server vero la rifiuterebbe. L'impossibilità strutturale dell'incidente che affligge password e codici SMS — inserire credenziali genuine in un sito falso — è la differenza di fondo dalle contromisure che si affidano ad addestramento e vigilanza.
Se perdo lo smartphone, resto chiuso fuori dagli account?
Se è una passkey sincronizzata — una conservata in iCloud Keychain o Google Password Manager — la si può ripristinare su un dispositivo nuovo connesso allo stesso Apple ID o account Google. Detto questo, per ripristinare la cassaforte cifrata end-to-end non basta la password dell'account: serve una verifica dell'identità aggiuntiva, come l'inserimento del blocco schermo (passcode) del dispositivo precedente, quindi se si perdono anche quei mezzi di recupero il ripristino può non essere possibile. Conta non affidare tutto a un solo telefono. Le passkey vincolate al dispositivo (chiavi di sicurezza, Windows Hello e simili) condividono il destino del dispositivo, quindi per gli account importanti la pratica standard è registrare più di una passkey. La maggior parte dei servizi consente di registrare più passkey su un solo account. Si noti che il modo di invalidare una passkey persa cambia per tipo. Per una passkey sincronizzata, poiché le copie su ogni dispositivo sono la stessa unica credenziale, prima si elimina il dispositivo perso o si fa un wipe remoto dal lato dell'account di piattaforma per disattivare la copia su quel dispositivo (eliminare la passkey nelle impostazioni dell'account del servizio invalida in un colpo le copie su tutti i dispositivi). Per una passkey vincolata al dispositivo, eliminare dal lato del servizio la passkey di quell'autenticatore invalida solo la chiave persa. Per l'uso in organizzazione è importante progettare insieme sia «la ridondanza perché l'utente possa riprendersi da solo» sia «una procedura perché l'amministratore la revochi in caso di perdita».
Anche una passkey ha debolezze?
Sì. Però è più preciso dire che il posto della debolezza si sposta. Poiché l'autenticazione in sé è irrigidita dalla crittografia a chiave pubblica, gli attaccanti mirano invece alle zone circostanti più deboli. In concreto: se restano mezzi legacy come password o SMS, quello resta l'anello più debole; c'è il trucco di abusare del flusso di recupero dell'account per farsi registrare la passkey dell'attaccante; e per le passkey sincronizzate il dirottamento dell'account cloud in sé diventa un nuovo punto di guasto singolo. Inoltre un attacco che ruba il cookie di sessione dopo l'accesso non viene fermato da una passkey, quindi le minacce non correlate non spariscono e basta. Introdurla va progettato non solo come «aggiungere le passkey» ma anche irrigidendo il flusso di recupero e riducendo in modo pianificato i mezzi di fallback.

Profilo dell’autore

Pagina di presentazione dell’autore dell’articolo.

Go Komura

Rappresentante di KomuraSoft LLC

Specializzato nello sviluppo di software Windows, nella consulenza tecnica e nell’analisi dei malfunzionamenti, soprattutto nei progetti con sistemi esistenti e guasti difficili da riprodurre.

Contattaci
Torna al blog