Che cos'è WebAuthn? Definizione, esempi e best practice

WebAuthn è lo standard W3C per l'autenticazione senza password e resistente al phishing. Scopri come funziona, gli errori comuni di implementazione e le best practice aziendali.

Che cos'è WebAuthn?

Le password falliscono. Vengono sottoposte a phishing, stuffing, spraying e dump. Il Data Breach Investigations Report (DBIR) 2026 di Verizon ha rilevato un abuso delle credenziali nel 39% di tutte le violazioni, la singola tecnica più pervasiva nel suo dataset, motivo per cui i difensori danno priorità ai controlli che rimuovono le password dal percorso di accesso. WebAuthn è lo standard del World Wide Web Consortium (W3C) creato esattamente per questo.

WebAuthn, abbreviazione di Web Authentication, è uno standard web del W3C che definisce un'API del browser per creare e utilizzare credenziali forti basate su chiave pubblica per autenticare gli utenti alle applicazioni web. Invece di scambiare segreti condivisi come le password, WebAuthn utilizza la crittografia asimmetrica: il tuo autenticatore genera una coppia di chiavi univoca per ogni sito, mantiene la chiave privata bloccata all'interno di hardware sicuro e condivide con il server solo la chiave pubblica.

La specifica del W3C lo definisce formalmente come "un'API che consente la creazione e l'uso di credenziali forti, attestate, con ambito definito e basate su chiave pubblica da parte delle applicazioni web, allo scopo di autenticare fortemente gli utenti". In termini pratici, questo significa che puoi accedere alle applicazioni web usando una scansione dell'impronta digitale, lo sblocco facciale o una chiave di sicurezza fisica, e il server non riceve mai nulla che un attaccante possa riutilizzare.

WebAuthn è un componente fondamentale del progetto FIDO2, sviluppato in coordinamento con la Fast Identity Online (FIDO) Alliance. FIDO2 abbina WebAuthn (il livello API del browser) a CTAP (Client to Authenticator Protocol), che gestisce la comunicazione tra il tuo dispositivo autenticatore e il browser tramite USB, near-field communication (NFC) o Bluetooth Low Energy (BLE). Insieme, costituiscono la base per un'autenticazione senza password e resistente al phishing sul web.

Due incidenti mostrano il costo del modello basato su password su larga scala. Nel 2021, gli attaccanti hanno raggiunto Colonial Pipeline tramite un profilo legacy di virtual private network (VPN) che non era destinato a essere in uso, come ha dichiarato al Senato degli Stati Uniti il CEO dell'azienda. Colonial ha fermato l'oleodotto per contenere l'attacco e ha pagato un riscatto di 4,4 milioni di dollari a un affiliato DarkSide, l'operazione ransomware descritta in un avviso CISA. Il Department of Justice ha successivamente sequestrato 2,3 milioni di dollari di quella somma. Nel 2023, MGM Resorts ha riportato un impatto finanziario negativo stimato di 100 milioni di dollari da un incidente informatico iniziato con social engineering contro i flussi di lavoro dell'identità, secondo un 8-K di ottobre 2023. Entrambi gli incidenti ruotavano attorno a un segreto riutilizzabile. WebAuthn lo rimuove dal percorso di accesso.

WebAuthn vs autenticazione tradizionale

L'autenticazione tradizionale si basa su segreti condivisi. Password, codici monouso e approvazioni push trasmettono tutti dati che un attaccante può intercettare, riprodurre o sottoporre a phishing in tempo reale. WebAuthn cambia il modello sostituendo i segreti condivisi con la crittografia a chiave pubblica, in cui la chiave privata non lascia mai l'hardware dell'autenticatore e nulla di riutilizzabile attraversa la rete.

Le differenze contano soprattutto nei punti in cui i metodi tradizionali si interrompono:

• Resistenza al phishing. L'autenticazione basata su password e OTP può essere catturata da proxy di phishing in tempo reale. Le credenziali WebAuthn sono vincolate crittograficamente al dominio di origine, quindi una credenziale registrata su login.example.com non si autenticherà contro login-example.com o qualsiasi altro dominio simile. Il browser applica questo vincolo a livello di protocollo, indipendentemente dal giudizio dell'utente.
• Esposizione lato server. I sistemi tradizionali archiviano hash di password o segreti condivisi che diventano obiettivi di alto valore nelle violazioni dei database. WebAuthn archivia solo chiavi pubbliche. Una compromissione completa del server non fornisce a un attaccante nulla che possa usare per impersonare un utente.
• Riutilizzo delle credenziali. Gli utenti riutilizzano le password tra servizi, il che rende il credential stuffing efficace su larga scala. WebAuthn genera una coppia di chiavi univoca per ogni relying party, quindi una credenziale compromessa in un servizio ha valore zero in un altro.
• Attrito per l'utente vs compromesso sulla sicurezza. Password più lunghe e rotazione frequente migliorano la sicurezza sulla carta ma peggiorano l'usabilità. WebAuthn elimina questo compromesso: una scansione dell'impronta digitale o lo sblocco facciale forniscono una garanzia di autenticazione più forte di qualsiasi policy sulle password, con meno attrito per l'utente.

L'effetto netto è che WebAuthn elimina i tre vettori responsabili della maggior parte delle violazioni basate su credenziali: phishing, furto lato server e riutilizzo tra siti. Comprendere queste differenze pone le basi per capire come i componenti del protocollo applicano queste proprietà.

Componenti chiave di WebAuthn

WebAuthn opera su un'architettura a tre parti definita dalla specifica W3C.

Authenticator: è l'entità crittografica che genera coppie di chiavi e firma le asserzioni di autenticazione. Gli autenticatori rientrano in due categorie:

• Platform authenticators sono integrati nel sistema operativo del tuo dispositivo: Windows Hello, Touch ID, Face ID. Si registrano con attrito quasi nullo, ma vengono persi se il dispositivo viene perso.
• Roaming (cross-platform) authenticators sono dispositivi hardware portatili come YubiKeys e chiavi di sicurezza FIDO. Funzionano su più dispositivi ma richiedono distribuzione fisica e gestione dell'inventario.

Qualunque tipo tu scelga, il modello di sicurezza resta lo stesso: l'autenticatore crea una coppia di chiavi univoca per ogni relying party e la chiave privata non lascia mai il perimetro sicuro dell'autenticatore.

Relying Party (RP): è la tua applicazione web: JavaScript lato client che richiama l'API WebAuthn più un componente lato server che gestisce l'archiviazione e la verifica delle credenziali. L'RP archivia solo la chiave pubblica. L'RP ID, in genere il tuo nome di dominio, funge da ancora crittografica per il binding dell'origine.

User Agent (Browser): il browser media tutte le interazioni tra autenticatori e relying party. Applica le policy di origine, impedisce l'uso improprio delle credenziali tra domini e preserva la privacy dell'utente: le credenziali registrate in un'origine non possono essere usate da un'altra, ed è questo che blocca il phishing a livello di protocollo.

WebAuthn definisce anche un framework di attestazione che consente agli autenticatori di dimostrare crittograficamente la propria autenticità durante la registrazione. La tua azienda può quindi verificare che le credenziali provengano da modelli di autenticatore affidabili e approvati dall'IT, anziché da dispositivi sconosciuti o di fascia consumer. Il FIDO Metadata Service fornisce un meccanismo live di revoca e advisory per i modelli di autenticatore.

Una volta compresi gli attori e i confini di fiducia, puoi mappare le due cerimonie e vedere esattamente dove la verifica può fallire.

Come funziona WebAuthn

WebAuthn definisce due cerimonie crittografiche: registrazione (creazione della credenziale) e autenticazione (verifica dell'asserzione). Entrambe seguono un protocollo challenge-response.

1. Registrazione (creazione della credenziale): il tuo server genera una challenge crittograficamente casuale e la invia al client insieme alle informazioni del relying party, ai dettagli dell'account utente e agli algoritmi crittografici accettabili. Il client richiama navigator.credentials.create(). L'autenticatore richiede il consenso esplicito dell'utente, genera una nuova coppia di chiavi asimmetriche e restituisce un oggetto di attestazione contenente la chiave pubblica, la challenge firmata, l'ID della credenziale e (facoltativamente) una catena di certificati di attestazione. Il tuo server verifica l'attestazione, convalida la firma, conferma che la chiave pubblica corrisponda agli algoritmi richiesti e archivia la chiave pubblica della credenziale, l'ID della credenziale e il contatore di firma. Protezione critica: anche con parametri identici, navigator.credentials.create() genera una nuova credenziale a ogni chiamata. Devi usare il parametro excludeCredentials per evitare registrazioni duplicate.
2. Autenticazione (verifica dell'asserzione): il tuo server genera una nuova challenge e la invia al client con un elenco di ID credenziali consentiti. Il client richiama navigator.credentials.get(). L'autenticatore verifica la presenza o l'identità dell'utente (in base alla tua policy), quindi firma la challenge con la chiave privata archiviata. Il tuo server recupera la chiave pubblica archiviata, verifica la firma dell'asserzione, convalida la corrispondenza della challenge, controlla i flag di presenza/verifica dell'utente, conferma che l'origine e l'RP ID corrispondano e verifica che il contatore di firma sia stato incrementato.

La verifica del contatore di firma è la tua difesa contro gli autenticatori clonati. Se il contatore non aumenta come previsto, hai evidenza di duplicazione della credenziale.

Per la conformità AAL2, devi applicare la User Verification (UV), non solo la User Presence (UP). Secondo la guida sugli autenticatori sincronizzabili, i verificatori devono indicare che la UV è preferita e ispezionare le risposte per confermare che il flag UV sia impostato.

Come le organizzazioni implementano WebAuthn

Vedere dove WebAuthn viene eseguito in produzione risponde alla domanda che la maggior parte dei valutatori pone davvero: è stato dimostrato su larga scala?

• Google Accounts è il benchmark più chiaro. Google ha iniziato a distribuire le passkey a maggio 2023 e le ha rese predefinite per gli account personali nell'ottobre 2023. Entro un anno dal lancio, le passkey erano state utilizzate oltre un miliardo di volte su più di 400 milioni di account, e Google ha riferito che le passkey venivano già usate per l'autenticazione più spesso di SMS OTP e app di autenticazione combinate su base giornaliera.
• GitHub ha citato WebAuthn come l'opzione 2FA più forte disponibile quando ha reso obbligatoria la 2FA nel 2023 per tutti i contributor, definendo le chiavi di sicurezza fisiche e gli autenticatori di piattaforma come Windows Hello e Face ID i metodi meno vulnerabili al phishing.
• Le piattaforme commerciali hanno seguito: Amazon, PayPal, Shopify, DocuSign e Kayak, che ha ridotto del 50% il tempo medio di registrazione e accesso, hanno tutte introdotto l'accesso supportato da WebAuthn. Queste implementazioni confermano che WebAuthn funziona su scala consumer, gestisce i flussi di recupero e si integra con le architetture standard degli identity provider.

Una volta comprese le cerimonie e le implementazioni nel mondo reale, la decisione successiva è quale tipo di autenticatore si adatta al tuo ambiente.

Tipi di autenticatori WebAuthn

La scelta dell'autenticatore determina il livello di garanzia della sicurezza, l'esperienza utente e l'overhead operativo della tua implementazione WebAuthn. Ogni tipo comporta compromessi distinti che contano nella pianificazione aziendale.

1. Platform authenticators sono incorporati nel sistema operativo e nell'hardware del dispositivo. Windows Hello utilizza un PIN supportato da Trusted Platform Module (TPM), riconoscimento facciale o impronta digitale. I dispositivi Apple usano Touch ID o Face ID supportati da Secure Enclave. I dispositivi Android usano impronta digitale o sblocco facciale tramite Google Play Services. I platform authenticators 1carry comportano il minor attrito di registrazione perché gli utenti dispongono già dell'hardware, e la verifica biometrica soddisfa i requisiti di user verification (UV) per la conformità AAL2 senza passaggi aggiuntivi. Il limite è che le credenziali sono legate al dispositivo. Se un utente perde il laptop o il telefono, tali credenziali vengono perse a meno che non si utilizzino passkey sincronizzate.
2. Roaming (cross-platform) authenticators sono token hardware portatili, come YubiKeys, chiavi Feitian BioPass o altre chiavi di sicurezza FIDO2, che si collegano tramite USB, NFC o BLE. Funzionano su più dispositivi e sistemi operativi, il che li rende la scelta standard per accessi privilegiati, ambienti con workstation condivise e casi d'uso ad alta garanzia. Il compromesso è la logistica di distribuzione: devi acquistare, spedire, inventariare e gestire dispositivi fisici, e gli utenti devono portarli con sé.
3. Passkey sincronizzate sono una categoria più recente in cui le credenziali WebAuthn si sincronizzano tramite un password manager di piattaforma (iCloud Keychain, Google Password Manager o un gestore di terze parti come 1Password). Le passkey sincronizzate riducono il problema del recupero in caso di perdita del dispositivo perché la credenziale sopravvive su qualsiasi dispositivo connesso allo stesso account. Per la maggior parte degli utenti aziendali, questo elimina il principale punto di attrito nell'adozione di WebAuthn. Il compromesso è che la sicurezza della tua autenticazione ora dipende in parte dalla sicurezza dell'account di piattaforma che ospita la credenziale sincronizzata. Per ambienti ad alta garanzia, le credenziali vincolate al dispositivo con chiavi di backup gestite dall'IT restano la scelta più forte.

La maggior parte delle implementazioni aziendali utilizza una combinazione: autenticatori di piattaforma per l'uso quotidiano, una chiave roaming come backup registrato e passkey sincronizzate dove il profilo di rischio lo consente. Scegliere il giusto mix dipende dai tuoi requisiti di garanzia, dalla tua popolazione di utenti e da quanto overhead operativo puoi assorbire.

La decisione sull'autenticatore influenza direttamente le proprietà di sicurezza che ottieni, ed è ciò che tratta la sezione successiva.

Vantaggi di sicurezza di WebAuthn

WebAuthn offre vantaggi di sicurezza concreti in termini di resistenza al phishing, esposizione lato server, conformità normativa e prevenzione degli attacchi cross-site:

• Resistenza al phishing a livello di protocollo. WebAuthn vincola crittograficamente le credenziali all'origine. Il commento della FIDO Alliance al NIST ha avvertito che gli attaccanti hanno raggiunto gli autenticatori AAL2 che non sono resistenti al phishing. WebAuthn colma questa lacuna.
• Nessun segreto condiviso sul server.Il modello crittografico a chiave pubblica di FIDO2 elimina la necessità di condividere segreti tra l'identity provider e l'autenticatore, ciò che il NIST SP 800-63B-4 definisce resistenza alla compromissione del verificatore. Una violazione completa del database non produce nulla che un attaccante possa riprodurre.
• Allineamento normativo. WebAuthn soddisfa i requisiti AAL2 resistenti al phishing del NIST SP 800-63B-4. Il memorandum M-22-09 dell'Office of Management and Budget (OMB) del governo degli Stati Uniti cita direttamente lo standard W3C Web Authentication come approccio resistente al phishing per le agenzie federali. Le organizzazioni regolamentate ottengono un percorso di conformità chiaro e verificabile.
• Eliminazione degli attacchi legati al fattore umano. Il Verizon DBIR 2026   ha rilevato l'elemento umano nel 62% delle violazioni. WebAuthn rimuove due superfici di attacco umane critiche: la scelta di password deboli e la suscettibilità al phishing. Gli utenti non possono scegliere password deboli quando non ci sono password.
• Prevenzione del credential stuffing cross-site. Ogni credenziale è crittograficamente limitata a un dominio specifico, rendendo il credential stuffing molto meno efficace tra servizi.

Queste proprietà di sicurezza non sono teoriche. Le organizzazioni che hanno implementato WebAuthn su larga scala le hanno già validate in produzione, e i casi d'uso coprono quasi ogni settore verticale.

Casi d'uso comuni di WebAuthn

L'adozione di WebAuthn è concentrata negli scenari in cui gli attacchi basati su credenziali comportano il maggiore impatto sul business. Questi sono i modelli di implementazione che compaiono più frequentemente negli ambienti di produzione.

• Accessi privilegiati e consolle di amministrazione. Portali VPN, console di gestione cloud e pannelli di amministrazione dell'infrastruttura sono gli obiettivi di maggior valore per il furto di credenziali. Implementare WebAuthn come secondo fattore obbligatorio, o come metodo primario senza password, per questi punti di accesso rimuove la superficie di attacco che i kit di phishing e i dump di credenziali sfruttano in modo più aggressivo. Questa è in genere la prima fase di qualsiasi rollout aziendale.
• Accesso rivolto ai clienti per servizi finanziari e sanità. I settori regolamentati in cui la compromissione delle credenziali attiva notifiche di violazione, sanzioni normative e perdite finanziarie dirette stanno adottando le passkey per l'autenticazione dei clienti. Applicazioni bancarie, portali pazienti e piattaforme assicurative usano WebAuthn per soddisfare sia i requisiti di conformità (PCI DSS, controlli di accesso HIPAA) sia l'obiettivo operativo di ridurre le frodi di account takeover.
• Ambienti con workstation condivise e chioschi. Ospedali, stabilimenti produttivi e attività retail utilizzano terminali condivisi in cui l'accesso basato su password è lento e soggetto a shoulder-surfing. Gli autenticatori roaming (chiavi di sicurezza abilitate NFC o soluzioni badge-tap) autenticano gli utenti in pochi secondi senza digitare credenziali su un dispositivo condiviso.
• Single sign-on (SSO) della forza lavoro. Implementare WebAuthn a livello di identity provider (IdP), tramite piattaforme come Okta, Azure AD o Ping Identity, protegge ogni applicazione downstream in un ambiente federato con una singola registrazione. Questo è il percorso più efficiente verso una copertura ampia perché implementi WebAuthn una volta nell'IdP e ogni relying party Security Assertion Markup Language (SAML) o OpenID Connect (OIDC) eredita l'autenticazione resistente al phishing.

Ognuno di questi casi d'uso rafforza lo stesso principio: più ti avvicini all'eliminazione dei segreti riutilizzabili dal tuo flusso di autenticazione, meno percorsi di attacco basati su credenziali restano aperti. Detto questo, implementare WebAuthn su larga scala introduce una complessità operativa che i team devono pianificare.

Sfide e limitazioni di WebAuthn

Il modello di sicurezza di WebAuthn è solido, ma le implementazioni aziendali fanno emergere una complessità operativa che i team sottostimano costantemente:

• Gestione del ciclo di vita delle credenziali. La modalità di errore primaria nelle implementazioni aziendali di WebAuthn è operativa, non crittografica. Hai bisogno di processi documentati per la distribuzione degli autenticatori, la revoca delle credenziali in caso di perdita del dispositivo, policy di rinnovo e supporto agli utenti per i guasti di autenticazione. La guida FIDO sul ciclo di vita copre in dettaglio le fasi di registrazione, recupero e revoca.
• Selezione del tipo di autenticatore. Devi affrontare una decisione strategica tra autenticatori di piattaforma (costo di distribuzione nullo, persi con il dispositivo), autenticatori roaming (portatili ma che richiedono distribuzione fisica) e approcci ibridi. Ognuno comporta diversi livelli di garanzia, requisiti di recupero e overhead operativo.
• Integrazione con applicazioni legacy. Non tutte le applicazioni nel tuo ambiente supportano WebAuthn in modo nativo. Devi affrontare l'integrazione con protocolli di federazione come SAML, OAuth e OpenID Connect. Questa è una sfida significativa per le organizzazioni con topologie complesse di federazione dell'identità.
• Decisioni sull'architettura del server FIDO. Devi scegliere tra integrare un server FIDO nel tuo identity provider esistente, distribuire un server FIDO standalone o usare un modello FIDO-server-as-a-service. Ogni scelta influisce sull'architettura di archiviazione delle credenziali, sulle procedure di disaster recovery e sull'ambito del rollout. La guida all'implementazione del server FIDO copre in dettaglio i compromessi.
• Il compromesso delle credenziali sincronizzate. La sincronizzazione delle passkey tramite i principali password manager di piattaforma riduce drasticamente l'attrito per l'utente ma trasferisce una parte della sicurezza dell'autenticazione alla sicurezza dell'account di piattaforma. Dove i requisiti di garanzia sono più elevati, le credenziali vincolate al dispositivo con chiavi di backup gestite dall'IT restano ancora la scelta più forte.

Oltre alla complessità operativa, specifiche decisioni di implementazione creano un'esposizione più duratura:

• Trattare tutta la MFA come resistente al phishing. Questo è l'errore con l'impatto più elevato. Implementare TOTP, SMS OTP o MFA con notifica push e dichiarare la conformità resistente al phishing ti lascia esposto. I proxy di phishing in tempo reale catturano e riproducono entrambi i fattori in questi approcci. Solo WebAuthn con verifier name binding o channel binding raggiunge una vera resistenza al phishing.
• Consentire la registrazione di credenziali non autenticata. CVE-2021-3632 lo ha dimostrato in Keycloak, dove chiunque poteva registrare un nuovo dispositivo di sicurezza quando non esisteva alcun dispositivo per un account utente. La registrazione deve avvenire all'interno di una sessione già autenticata o tramite processi out-of-band verificati.
• Progettazione scadente del flusso di registrazione. Una registrazione macchinosa crea resistenza da parte degli utenti e aumenta il volume dei ticket di supporto. Il tuo portale di registrazione dovrebbe guidare gli utenti attraverso la registrazione all'interno di una sessione autenticata, fornire istruzioni chiare sugli autenticatori accettabili e spiegare perché dispositivi specifici sono stati rifiutati.
• Assenza di meccanismi di fallback e recupero. Implementare WebAuthn senza procedure di fallback documentate per perdita del dispositivo, guasto hardware o problemi biometrici crea scenari di blocco dell'accesso. Hai bisogno di autenticatori di backup preregistrati, codici di accesso di emergenza per amministratori IT e processi di verifica di persona.
• Implementare WebAuthn isolatamente dal tuo stack di sicurezza. WebAuthn non è una soluzione standalone. Secondo il NIST SP 1800-35, dovrebbe integrarsi con la valutazione continua dell'autenticazione, la verifica dello stato di salute del dispositivo, policy di accesso context-aware e la tua infrastruttura di sicurezza degli endpoint. In una architettura zero trust, WebAuthn diventa uno dei segnali più forti che puoi usare nelle decisioni di accesso.

Queste sfide sono risolvibili con la giusta pianificazione. Le pratiche seguenti coprono le decisioni chiave che separano un'implementazione pronta per la produzione da una proof of concept.

Best practice per implementare WebAuthn

Le pratiche seguenti coprono le decisioni chiave che separano un'implementazione WebAuthn pronta per la produzione da una proof of concept.

Applica la user verification per AAL2. Imposta userVerification: "required" sia nelle cerimonie di registrazione sia in quelle di autenticazione e convalida lato server il flag UV. Non fare affidamento su "preferred" per implementazioni soggette a requisiti di conformità.

Usa l'attestazione per applicare la policy dell'autenticatore. Controlla le attestazioni durante la registrazione e consenti solo autenticatori che soddisfano i tuoi requisiti di sicurezza (ad esempio, certificazione FIDO L1+). Usa allowlist basate su AAGUID (identificatore del modello di autenticatore) e integra il FIDO Metadata Service per controlli live sullo stato degli autenticatori.

Implementa per fasi. La raccomandazione FIDO sul rollout graduale è un approccio a fasi:

1. WebAuthn come secondo fattore per applicazioni ad alto rischio (VPN, accessi privilegiati, console di amministrazione)
2. Rollout del secondo fattore a livello di piattaforma mentre si costruisce il supporto operativo
3. Credenziali individuabili e flussi senza password per popolazioni di utenti mature
4. Completamente senza password con autenticazione legacy ritirata per gli utenti registrati

Questo approccio ti consente di convalidare policy, supporto e flussi di recupero prima di rendere WebAuthn l'impostazione predefinita.

Implementa una strategia di recupero multi-authenticator. Registra almeno due autenticatori per utente: uno primario (ad esempio, autenticatore di piattaforma per l'uso quotidiano) e uno di backup (ad esempio, chiave di sicurezza conservata in modo sicuro). Mostra chiaramente le credenziali di recupero registrate nelle impostazioni dell'account utente.

Verifica i contatori di firma. Controlla che il contatore di firma aumenti monotonamente a ogni autenticazione. Un contatore che non aumenta segnala un autenticatore potenzialmente clonato.

Separa gli errori attesi da quelli inattesi. Tieni traccia esplicita degli errori WebAuthn. Raggruppa NotAllowedError, AbortError e gli errori passkey di Credential Manager come segnali distinti, così da poter differenziare l'attrito per l'utente dalle anomalie di sicurezza.

Seguire queste pratiche porterà la tua implementazione WebAuthn a uno stato pronto per la produzione. Ma anche un rollout WebAuthn configurato correttamente non costituisce una difesa completa dell'identità. Gli attacchi che aggirano completamente WebAuthn richiedono controlli che operano oltre la cerimonia di accesso: hijacking della sessione, movimento laterale post-autenticazione e social engineering dell'help desk.

Come SentinelOne migliora la sicurezza dell'identità

WebAuthn riduce il replay delle credenziali, ma non blocca ogni attacco sul percorso dell'identità che vedrai in produzione. Devi comunque gestire il furto di token di sessione, la compromissione del dispositivo, il social engineering dell'help desk e il movimento laterale post-auth.

The Singularity™ Platform colma questa lacuna correlando il contesto di identità ed endpoint:

• Singularity Identity rileva comportamenti sospetti legati all'identità e risponde quando gli avversari prendono di mira i servizi di directory e i flussi di lavoro SSO. Copre l'infrastruttura di identità che WebAuthn non tocca mai.
• Singularity Endpoint esegue modelli AI comportamentali e statici sul dispositivo per bloccare malware che rubano credenziali e attività hands-on-keyboard che aggirano completamente i controlli di accesso. Segnala pattern dannosi in tempo reale senza intervento umano, aspetto importante quando gli attaccanti prendono di mira le sessioni invece delle password.
• Purple AI™ ragiona sui tuoi dati di sicurezza per guidare le indagini e raccomandare le azioni successive. Uno Snapshot IDC 2025 ha rilevato che i clienti identificano le minacce il 63% più velocemente, un aspetto importante quando devi determinare se un accesso WebAuthn non riuscito sia attrito per l'utente o una campagna di phishing attiva.

Insieme presidiano il percorso di attacco all'identità su entrambi i lati dell'accesso.

Se tratti WebAuthn come un segnale forte all'interno del tuo più ampio programma di difesa dal phishing e del flusso di lavoro di incident response, puoi ridurre sia il rischio di takeover sia il tempo che impieghi per dimostrare cosa è accaduto.

Richiedi una demo per vedere come SentinelOne colma il divario tra autenticazione e difesa completa dell'identità.

Fai il tour

Ottieni protezione dell’identità in tempo reale e visibilità end-to-end negli ambienti ibridi per rilevare esposizioni, bloccare l’abuso delle credenziali e ridurre il rischio legato all’identità.

Punti chiave

WebAuthn è lo standard W3C per l'autenticazione web senza password e resistente al phishing che utilizza la crittografia a chiave pubblica. Vincola crittograficamente le credenziali a domini specifici, rendendo il replay delle credenziali architetturalmente impossibile. 

Un'implementazione aziendale di successo richiede rollout graduale, policy dell'autenticatore basata su attestazione, strategie di recupero multi-dispositivo e integrazione con il tuo stack di sicurezza più ampio.

FAQ

Che cos'è WebAuthn nella cybersecurity?

WebAuthn, abbreviazione di Web Authentication, è uno standard web del W3C che definisce un'API del browser per creare e utilizzare credenziali robuste basate su chiavi pubbliche per autenticare gli utenti nelle applicazioni web. 

Invece delle password, utilizza la crittografia asimmetrica: il tuo autenticatore genera una coppia di chiavi univoca per ogni sito, conserva la chiave privata in hardware sicuro e condivide solo la chiave pubblica con il server. Questo rende il furto di credenziali e gli attacchi di phishing molto più difficili da eseguire.

Quali attacchi previene WebAuthn?

La principale proprietà di sicurezza di WebAuthn è la resistenza al phishing tramite il binding crittografico del dominio. Quando registri una credenziale, questa viene associata all'origine esatta della relying party. Quando ti autentichi, il browser include crittograficamente tale origine nella risposta firmata, quindi un attaccante su un dominio simile non può riutilizzare la tua credenziale. 

Oltre al phishing, WebAuthn elimina il furto di credenziali lato server perché vengono archiviate solo chiavi pubbliche e blocca il credential stuffing perché ogni credenziale è limitata a un singolo dominio.

WebAuthn è la stessa cosa di FIDO2?

WebAuthn e FIDO2 sono correlati ma non identici. FIDO2 è il progetto più ampio, sviluppato dalla FIDO Alliance in coordinamento con il W3C, che combina due specifiche: WebAuthn (l'API del browser per creare e verificare credenziali a chiave pubblica) e CTAP (Client to Authenticator Protocol, che gestisce la comunicazione tra il tuo autenticatore e il browser tramite USB, NFC o BLE). 

WebAuthn è la componente di FIDO2 rivolta al web. Implementi WebAuthn nella tua applicazione. CTAP viene eseguito tra l'hardware dell'autenticatore e il browser.

In che modo WebAuthn supporta la sicurezza Zero Trust?

WebAuthn fornisce uno dei segnali di autenticazione più forti in un architettura zero trust. Secondo NIST SP 1800-35, si integra con la valutazione continua dell'autenticazione, la verifica dello stato di integrità del dispositivo e le policy di accesso basate sul contesto. Poiché le credenziali WebAuthn sono resistenti al phishing e vincolate al dominio, fungono da passaggio di verifica dell'identità ad alta affidabilità che alimenta decisioni di accesso più ampie. 

In pratica, l'abbinamento di WebAuthn con la telemetria degli endpoint e l'analisi comportamentale offre al motore di policy un segnale di autenticazione più affidabile rispetto a qualsiasi password o metodo MFA legacy.

Quali browser e piattaforme supportano WebAuthn?

Secondo Can I Use, WebAuthn è disponibile in circa il 95% dei browser globali. Tutti i browser desktop evergreen lo supportano: Chrome (v67+), Firefox (v60+), Safari (v14+) ed Edge (v18+). Su mobile, Chrome per Android, Safari su iOS e Samsung Internet supportano tutti WebAuthn. 

Per gli autenticatori di piattaforma, Windows 10+ include Windows Hello (riconoscimento facciale, impronta digitale, PIN tramite TPM), macOS/iOS 16+ supporta Touch ID e Face ID con sincronizzazione del Portachiavi iCloud per le passkey, e Android 9+ fornisce sblocco tramite impronta digitale e riconoscimento facciale tramite Google Play Services. Permangono lacune nelle versioni meno recenti dei sistemi operativi e in alcune configurazioni browser aziendali con restrizioni.

Qual è la differenza tra WebAuthn e le passkey?

WebAuthn è la specifica API del W3C che i browser implementano per la creazione e l'autenticazione di credenziali a chiave pubblica. Le passkey sono un termine rivolto agli utenti per indicare le credenziali WebAuthn, spesso riferito in particolare alle credenziali sincronizzate (supportate dal cloud) che si sincronizzano tra i tuoi dispositivi tramite i provider della piattaforma. 

Tutte le passkey utilizzano WebAuthn dietro le quinte, ma non tutte le credenziali WebAuthn sono passkey sincronizzate. Le credenziali WebAuthn vincolate al dispositivo restano legate a hardware specifico.

WebAuthn può sostituire tutte le forme di MFA?

WebAuthn può funzionare come autenticazione a fattore singolo (possesso dell'autenticatore), a due fattori (possesso più biometria o PIN) o a più fattori a seconda della configurazione. 

Per la conformità AAL2, è necessario applicare la verifica dell'utente (biometria o PIN) e convalidare lato server il flag UV. WebAuthn sostituisce i metodi MFA legacy come TOTP e SMS OTP, offrendo al contempo una resistenza al phishing più elevata rispetto a tutti questi metodi.

Cosa succede se un utente perde il proprio autenticatore WebAuthn?

Senza un piano di recupero, l'utente rimane bloccato fuori. La best practice consiste nel registrare almeno due autenticatori per utente: un dispositivo primario per l'uso quotidiano e un backup conservato in modo sicuro. 

Il processo di recupero dell'account dovrebbe includere anche codici di accesso di emergenza per gli amministratori IT e un percorso di verifica di persona per ambienti ad alta affidabilità in cui gli autenticatori di backup non sono disponibili.

WebAuthn funziona con i sistemi di identità federata?

Sì, ma l'integrazione richiede pianificazione. WebAuthn opera a livello di identity provider (IdP) negli ambienti federati che utilizzano SAML, OAuth o OpenID Connect. Il tuo IdP gestisce il processo WebAuthn, quindi emette token di federazione per le applicazioni downstream. 

Ciò significa che distribuisci WebAuthn presso l'IdP anziché in ogni singola applicazione, semplificando il rollout nei servizi federati.

In che modo WebAuthn protegge dagli attacchi man-in-the-middle?

Il browser include crittograficamente l'origine (dominio) nei dati firmati dall'autenticatore durante ogni processo di autenticazione. Un attaccante man-in-the-middle non può inoltrare un'asserzione di autenticazione a un dominio diverso perché la firma non sarà valida per nessuna origine diversa da quella in cui la credenziale è stata registrata. 

Questa protezione opera a livello di protocollo, indipendentemente da TLS o dalla consapevolezza dell'utente.