Il progetto di autenticazione deve includere registrazione, accesso e recupero. Un percorso forte perde parte del suo valore se una procedura alternativa permette di aggiungere un nuovo autenticatore sulla base di una sola email compromessa.
Obiettivo, pubblico e prerequisiti: valutare WebAuthn lungo registrazione, accesso, sessione e recupero. È rivolto a identity architect e team applicativi con un relying party di test, account dedicati e requisiti di autenticazione documentati.
Uso autorizzato: prova enrollment e recovery soltanto su tenant e applicazioni di laboratorio autorizzati. Non registrare autenticatori su account altrui e non raccogliere credenziali, challenge o dati biometrici reali.
La proprietà da richiedere
Il NIST SP 800-63B-4 distingue resistenza al phishing e resistenza al replay. Un codice OTP digitato può essere inoltrato a un verificatore legittimo da un sito impostore: il codice non è legato al verificatore e alla sessione specifica come richiesto per la resistenza al phishing.
Questa distinzione aiuta a scrivere un requisito misurabile. “Abbiamo due fattori” descrive una parte del sistema; non dimostra che l’autenticazione impedisca il relay dell’output. Definire per quali account e quali applicazioni sia necessaria quella proprietà, senza attribuire automaticamente un livello NIST all’intera organizzazione.
Il legame con la relying party
WebAuthn usa credenziali a chiave pubblica vincolate alla relying party. Il verificatore deve controllare challenge, origine e identificativo della relying party, insieme ai requisiti dell’operazione. Non è sufficiente ricevere un blob firmato senza verificare il contesto.
La chiave privata non viene trasmessa al sito come password. La presenza dell’utente e la verifica locale dell’utente sono proprietà distinte: toccare una chiave e verificare un PIN non sono sinonimi. Il relying party deve scegliere e validare i requisiti appropriati al proprio modello di rischio.
Sincronizzazione, hardware e livello di garanzia
Il NIST contempla autenticatori sincronizzabili nel quadro di requisiti applicabili fino ad AAL2; non attribuisce AAL3 a ogni passkey. Il requisito di non esportabilità della chiave ha implicazioni differenti. Valutare gestione del dispositivo, account di sincronizzazione e recupero invece di usare “passkey” come certificazione universale.
Per un progetto aziendale, documentare quali tipi siano consentiti per operatori privilegiati e quali per utenti ordinari. Verificare la compatibilità con dispositivi, browser e servizi federati realmente usati. Una scelta che costringe tutti a un fallback debole non raggiunge l’obiettivo di riduzione del rischio.
Evidenze riproducibili: provare enrollment e recovery
Proposta di collaudo: partire da un account di laboratorio, registrare un autenticatore principale e uno di riserva attraverso il percorso previsto. Simulare la perdita del primo senza interrompere le attività reali. Verificare quali prove richieda il supporto per rimuovere dispositivi o registrarne altri.
- La registrazione aggiuntiva richiede un’autenticazione sufficientemente forte?
- La modifica viene notificata e registrata con un’identità attribuibile?
- Il supporto può aggirare la policy con una procedura non tracciata?
- Il fallback mantiene le garanzie richieste per quell’applicazione?
- Un dispositivo smarrito può essere revocato senza lasciare credenziali ignote?
Limiti e mitigazioni: le sessioni restano parte del problema
La resistenza al phishing dell’autenticazione non impedisce ogni furto di sessione su un endpoint compromesso. Come valutazione operativa, controllare durata delle sessioni, revoca, ri-autenticazione per operazioni sensibili e accessi da dispositivi non gestiti. Non confondere la protezione della credenziale con il controllo di tutto ciò che accade dopo il login.
Il verbale di collaudo dovrebbe registrare applicazioni coperte, percorsi alternativi e problemi di recupero. Misurare adozione e uso dei fallback prima di dichiarare conclusa la migrazione.
Fonti essenziali
Riferimenti primari consultati il 3 ottobre 2026. Le procedure di analisi e gli scenari di laboratorio sono proposte editoriali: vanno adattati alla telemetria e alle versioni installate.
AUTORE
Redazione ThreatHunting.it
Da piu' di 30 anni sono appassionato di computers e tecnologia. il mio primo programma lo sviluppai in Basic nel 1989, non era un gran che :).. ma quella voglia di scrivere codici non mi ha piu' lasciato …
COMMUNITY
Non ci sono ancora commenti. Puoi iniziare tu la conversazione.