Chiave Residente WebAuthn: Credenziali Individuabili come Passkey

Le passkey e il protocollo sottostante WebAuthn stanno rivoluzionando il panorama dell'autenticazione. Tuttavia, configurare correttamente un server WebAuthn può essere un'impresa complicata. Le configurazioni errate non solo possono introdurre vulnerabilità, ma anche danneggiare le passkey esistenti se fosse necessario modificarle in seguito. Questo articolo ha lo scopo di aiutarvi a comprendere meglio le specifiche, spesso complesse, di WebAuthn e di consigliarvi le impostazioni più adatte al vostro caso d'uso.

WebAuthn opera con tre entità principali:

• Relying Party (RP): È il vostro servizio web che desidera autenticare un utente. Invia delle "sfide" (challenge) al client, verifica le risposte e gestisce la chiave pubblica di una passkey.
• Autenticatori: Sono i dispositivi che possono dimostrare il possesso di una credenziale. Esempi includono smartphone, laptop o chiavi di sicurezza (ad es. YubiKeys). Gli autenticatori possono essere specifici della piattaforma (come Windows Hello o Touch ID / Face ID di Apple) o multipiattaforma (come le chiavi di sicurezza, ad es. YubiKeys).
• Client: Tipicamente, si tratta di browser web o app native che agiscono da intermediari tra la RP e l'autenticatore. Facilitano la comunicazione, assicurando che i dati fluiscano in modo corretto e sicuro.

Want to try passkeys yourself in a passkeys demo?

Try Passkeys

Di seguito, descriviamo il flusso di dati generale durante un processo di autenticazione (sia login che registrazione).

1. Inizio dal client: Il processo inizia lato client, solitamente quando un utente tenta di accedere o registrarsi. Ad esempio, potrebbe cliccare su un pulsante "Accedi con WebAuthn" e il client invia una richiesta di sfida alla RP.
2. Richiesta della RP: La RP invia quindi una sfida al client. Questa sfida è un valore generato casualmente che garantisce l'autenticità della risposta successiva.
3. Dal client all'autenticatore: Durante la registrazione, il client chiede all'autenticatore di creare una nuova passkey generando la coppia di chiavi pubblica-privata corrispondente. Durante il login, il client chiede all'autenticatore di firmare la sfida. Questo avviene utilizzando la chiave privata sull'autenticatore, che corrisponde a una chiave pubblica precedentemente registrata e memorizzata sulla RP.
4. Risposta dell'autenticatore: Durante la registrazione, l'autenticatore invia la chiave pubblica al client. Durante il login, l'autenticatore firma la sfida e invia questa asserzione firmata al client.
5. Dal client alla RP: Il client inoltra questa nuova chiave pubblica / l'asserzione firmata alla RP.
6. Verifica della RP: La RP memorizza la chiave pubblica / verifica l'asserzione firmata utilizzando la chiave pubblica memorizzata. Se è valida, l'autenticazione ha successo.

Ben Gould

Head of Engineering

I’ve built hundreds of integrations in my time, including quite a few with identity providers and I’ve never been so impressed with a developer experience as I have been with Corbado.

10,000+ devs trust Corbado & make the Internet safer with passkeys. Got questions? We’ve written 150+ blog posts on passkeys.

Join Passkeys Community

Il processo di alto livello descritto sopra riguarda le procedure di registrazione e login con WebAuthn. Le passkey sono costruite su WebAuthn. Inizialmente, il termine "passkey" era usato come un'alternativa più memorabile e meno tecnica di WebAuthn per descrivere la stessa cosa. Inoltre, le passkey offrono più funzionalità rispetto allo standard WebAuthn, come la possibilità di sincronizzare le passkey tramite account cloud o gestori di password.

Per comprendere meglio le sezioni seguenti, definiamo alcuni termini importanti del protocollo WebAuthn per avere una base comune.

• ID della credenziale (Credential ID): L'ID della credenziale è un identificatore univoco assegnato a una specifica credenziale di chiave pubblica generata da un autenticatore. Permette alle Relying Party (RP) di identificare e selezionare la PublicKeyCredential corretta per i processi di autenticazione.
• PublicKeyCredential: È la struttura dati principale restituita dall'API WebAuthn del browser o delle app native. Comprende sia i dati di attestazione durante la registrazione sia i dati di asserzione durante il login. In sostanza, contiene i dati di cui la RP ha bisogno per verificare il processo.
• Attestazione: L'attestazione nel contesto WebAuthn serve come prova dell'origine e dell'integrità dell'autenticatore. Durante la registrazione, è un modo per l'autenticatore di dire: "Ho registrato in modo sicuro la credenziale dell'utente, ed ecco una dichiarazione che puoi usare per verificarlo". La Relying Party può quindi verificare che la firma provenga da un autenticatore specifico consentito (ad es. Yubikey). Non tutti gli autenticatori di passkey rispondono con tale attestazione, alcuni semplicemente non inviano dati utili (vedi qui l'elenco degli autenticatori di passkey). Ulteriori AAGUID (Authenticator Attestation GUID) che identificano altri autenticatori (principalmente chiavi di sicurezza, ad es. YubiKeys) possono essere trovati nel FIDO Alliance Metadata Service.
• Asserzione: Dopo il processo di registrazione, quando un utente cerca di accedere, l'autenticatore produce un'asserzione. L'asserzione è fondamentalmente la PublicKeyCredential + la sfida firmata. Questa asserzione dimostra che l'utente possiede la chiave privata legata alla chiave pubblica registrata, senza rivelare la chiave privata stessa. È il modo in cui l'autenticatore dice: "Questo è l'utente autentico e posso garantirlo".

Subscribe to our Passkeys Substack for the latest news.

Subscribe

Le chiavi residenti (RK) e le chiavi non residenti (NRK) sono due tipi di chiavi crittografiche utilizzate nel protocollo WebAuthn, e si differenziano principalmente per la loro posizione di archiviazione e il meccanismo di recupero.

Definizione:

Le chiavi residenti sono salvate direttamente sull'autenticatore stesso. Potrebbe trattarsi di una chiave di sicurezza (es. YubiKey), di un enclave sicuro della piattaforma (es. Secure Enclave dell'iPhone) o di un trusted platform module (TPM) su un laptop. L'UI condizionale (completamento automatico delle passkey) funziona solo per le chiavi residenti e il gruppo di lavoro WebAuthn attualmente richiede che le chiavi residenti siano considerate come passkey.

Nello screenshot seguente, si vede un elenco di tutte le chiavi residenti (ID credenziale, rpID, nome utente, nome visualizzato) memorizzate su una YubiKey. Le chiavi non residenti non sono nell'elenco, poiché non sono memorizzate sull'autenticatore:

Flusso di login:

Fonte: William Brown

Durante il processo di login, la Relying Party invia una richiesta senza specificare le credenziali al client (browser), che inizia a interrogare l'autenticatore (nel grafico: chiave di sicurezza). L'autenticatore individua tutte le chiavi residenti per la Relying Party corrispondente e il client (browser) seleziona la chiave residente desiderata. Questa chiave residente viene utilizzata per firmare la sfida. La firma viene inviata dall'autenticatore tramite il client alla Relying Party.

Vantaggi:

1. Esperienza Utente Semplificata: Uno dei vantaggi più significativi delle chiavi residenti è che l'autenticatore memorizza lo user handle (es. email, numero di telefono, nome utente) e può quindi precompilarlo per il login. Gli utenti non devono ricordare o inserire gli user handle, semplificando il processo di accesso, specialmente su dispositivi con capacità biometriche. Questo può avvenire anche automaticamente con l'UI condizionale.
2. Autenticazione specifica del dispositivo: Le chiavi residenti possono fornire un ulteriore livello di sicurezza legando l'autenticazione a un dispositivo specifico. Questo può essere particolarmente utile per i servizi che vogliono assicurarsi che gli utenti accedano da dispositivi affidabili.
3. UI condizionale (Completamento automatico delle passkey): L'UI condizionale funziona solo con chiavi residenti, offrendo l'esperienza di login più fluida (vedi sotto per i dettagli).

Svantaggi:

1. Limiti di archiviazione: Alcuni autenticatori hanno una capacità di archiviazione finita. Specialmente per le chiavi di sicurezza (es. YubiKeys), c'è spesso un limite al numero di chiavi residenti che possono memorizzare (la maggior parte ha un limite che va da 8 a circa 100 chiavi residenti). Una volta raggiunto questo limite, potrebbe essere necessario eliminare le chiavi più vecchie per fare spazio a quelle nuove, oppure l'utente potrebbe dover utilizzare un altro autenticatore.
2. Perdita dell'autenticatore: Se l'autenticatore, ad esempio una chiave di sicurezza (es. YubiKey) o uno smartphone, viene perso o danneggiato, tutte le chiavi residenti su quel dispositivo andranno perse. Ciò potrebbe bloccare l'accesso degli utenti a più servizi fino a quando non si registrano nuovamente o recuperano i loro account. La sincronizzazione delle chiavi tramite un account cloud (es. Portachiavi iCloud, Google Password Manager) o un moderno gestore di password (es. 1Password o Dashlane) previene questa perdita.
3. Preoccupazioni di sicurezza: Se un autenticatore con chiavi residenti viene rubato, un aggressore potrebbe tentare di estrarre le chiavi. Sebbene gli autenticatori moderni dispongano di robusti meccanismi di sicurezza per prevenire l'estrazione, ad esempio l'utente protegge il dispositivo con un PIN, un passcode o un gesto forte, il rischio, seppur minimo, esiste ancora.

Casi d'uso: Ideale per dispositivi in cui l'utente si autentica frequentemente, come smartphone o laptop personali.

Want to find out how many people use passkeys?

View Adoption Data

Definizione:

Le chiavi non residenti, al contrario, non sono salvate sull'autenticatore. Invece, l'autenticatore genera una nuova coppia di chiavi (basata sulla sua chiave master protetta internamente) e invia la chiave pubblica di questa nuova coppia al server (Relying Party) insieme all'ID della credenziale (che contiene un seme) durante la registrazione. Il server associa quindi questa chiave pubblica all'account dell'utente. Per le autenticazioni successive, l'autenticatore deriva nuovamente la chiave privata ricevendo l'ID della credenziale, estraendo il seme e combinandolo con la chiave master. Poiché la chiave è disponibile solo temporaneamente nella memoria protetta dell'autenticatore, nel linguaggio crittografico viene talvolta chiamata chiave effimera.

Flusso di login:

Fonte: William Brown

Durante il processo di login, la Relying Party deve prima identificare quale utente sta richiedendo l'autenticazione (ad es. chiedendo uno user handle, come email, numero di telefono o nome utente) e poi invia gli ID delle credenziali di cui è a conoscenza per l'utente richiedente al client (browser). Il client li inoltra all'autenticatore (qui: chiave di sicurezza). L'autenticatore utilizza l'ID della credenziale insieme alla chiave master dell'autenticatore per derivare la chiave privata temporanea, firma la sfida con la chiave generata e la restituisce al client (qui: browser), che la inoltra alla Relying Party. Le chiavi non residenti erano originariamente utilizzate come secondo fattore prima dell'introduzione delle passkey. Pertanto, identificare prima l'utente faceva parte del normale processo di login.

Vantaggi:

1. Scalabilità: Poiché le chiavi non residenti non risiedono sull'autenticatore, gli utenti possono avere un numero quasi illimitato di chiavi non residenti associate a vari servizi. Ciò è particolarmente vantaggioso per gli utenti che hanno account su numerose piattaforme.
2. Capacità di roaming: Le chiavi non residenti sono ideali per autenticatori mobili come le chiavi di sicurezza (ad es. YubiKey). Un utente può utilizzare la stessa chiave di sicurezza (es. YubiKey) per autenticarsi su più dispositivi e piattaforme, offrendo un'esperienza coerente.
3. Minore dipendenza dalla memoria dell'autenticatore: Con le giuste impostazioni del server WebAuthn, non c'è bisogno di preoccuparsi dei limiti di archiviazione dell'autenticatore. Questo può essere particolarmente vantaggioso per autenticatori con poca memoria, come le chiavi di sicurezza (es. YubiKeys).

Svantaggi:

1. UX inferiore a causa della richiesta dello User Handle: Lo svantaggio più grande delle chiavi non residenti è che lo user handle (es. email, numero di telefono, nome utente) deve essere fornito dall'utente, il che rende impossibile la precompilazione del nome utente tramite UI condizionale. Questo user handle deve essere legato all'ID della credenziale, necessario per calcolare la chiave avvolta dalla chiave effimera.
2. Potenziale di cattiva gestione: Le RP devono gestire e proteggere le associazioni tra account utente e chiavi pubbliche. Una cattiva gestione o vulnerabilità potrebbero portare a problemi di sicurezza.

Casi d'uso: Ideale per autenticatori mobili come le chiavi di sicurezza (es. YubiKeys) che vengono utilizzate su più servizi o piattaforme.

Immagina di avere una chiave di sicurezza (es. YubiKey) e di registrarla con due servizi online: Servizio A e Servizio B. Per il Servizio A, usi una chiave residente. Per il Servizio B, una chiave non residente. Quando ti autentichi al Servizio A, tocchi semplicemente la tua chiave di sicurezza (es. YubiKey) e sei dentro, senza bisogno di specificare un nome utente. Per il Servizio B, dovrai prima fornire il tuo nome utente nel browser / app nativa. Il servizio invia quindi l'ID della credenziale associato alla tua chiave di sicurezza (es. YubiKey), che rigenera la chiave privata effimera per l'autenticazione.

In sostanza, mentre sia le chiavi residenti che quelle non residenti migliorano la sicurezza sfruttando l'autenticazione crittografica, le loro esperienze utente e i meccanismi di archiviazione differiscono, adattandosi a vari casi d'uso.

Want to experiment with passkey flows? Try our Passkeys Debugger.

Try for Free

L'UI condizionale è una funzionalità fondamentale delle passkey / WebAuthn. Alleggerisce ulteriormente il carico per l'utente, che non solo non deve ricordare una password, ma non deve nemmeno ricordare lo user handle (es. email, numero di telefono, nome utente) con cui si è registrato a una Relying Party. Questo è un passo da gigante, specialmente nei casi in cui i servizi delle Relying Party vengono utilizzati solo occasionalmente.

Questo funziona perché non appena la pagina di login viene aperta, il server della Relying Party invia una sfida in background al client (ricorda che non è necessario inviare un ID credenziale in questa chiamata). Il client prende questa sfida, controlla quali passkey corrispondono all'ID della Relying Party su quell'autenticatore e offre la selezione tramite il menu di completamento automatico, dove l'utente può selezionare la passkey appropriata.

Inoltre, risparmia all'utente un clic aggiuntivo sul pulsante di login, perché non appena la passkey viene selezionata dal menu di completamento automatico, il processo di login inizia.

CTAP è un protocollo fondamentale dello standard FIDO2, che colma il divario di comunicazione tra client (come i browser) e autenticatori (come le chiavi di sicurezza, es. YubiKeys, o gli smartphone). Per comprendere meglio CTAP, diamo prima una breve occhiata alle diverse versioni del protocollo prima di analizzare l'impatto sulle chiavi residenti e non residenti.

La versione precedente, spesso definita Universal 2nd Factor (U2F), era progettata principalmente per l'autenticazione a due fattori. In U2F, il server fornisce una sfida e l'autenticatore fornisce una risposta, dimostrando il possesso della chiave privata. Tuttavia, U2F non supporta le chiavi residenti, il che significa che richiede sempre una ricerca lato server per identificare quale chiave utilizzare per un utente, poiché questo faceva parte del processo quando si chiedeva un secondo fattore.

Successore di U2F, CTAP2 ha introdotto il supporto per le chiavi residenti, consentendo l'autenticazione senza password e senza nome utente. Con le chiavi residenti, l'autenticatore memorizza il nome utente e l'ID della credenziale (insieme all'ID della Relying Party), eliminando la necessità per il server della Relying Party di fornirlo durante l'autenticazione. Questo è un passo significativo verso una UX più fluida.

Tuttavia, CTAP2 presenta delle sfide. Un problema notevole è la gestione delle chiavi residenti. Ad esempio, la cancellazione di una specifica chiave residente in un dispositivo CTAP2.0 richiede spesso un reset completo del dispositivo (quindi anche la tua chiave master viene resettata, il che significa che tutte le tue chiavi non residenti non funzioneranno più), il che non è user-friendly e può essere problematico in scenari in cui più chiavi residenti sono memorizzate su un singolo dispositivo. Questo rende le chiavi residenti su un dispositivo CTAP2.0 un impegno serio. Non si vuole certo riempire accidentalmente quello spazio limitato che si ha spesso, specialmente sulle chiavi di sicurezza (es. YubiKeys).

CTAP2.1 è una versione successiva di CTAP2, che introduce funzionalità e miglioramenti aggiuntivi al protocollo. Alcuni punti chiave di CTAP 2.1 includono:

• Migliore gestione delle chiavi residenti: CTAP 2.1 consente di gestire, aggiornare ed eliminare individualmente specifiche chiavi residenti dal proprio dispositivo.
• Attestazione aziendale: Questa funzione consente alle aziende di avere un maggiore controllo sulle chiavi utilizzate dai loro dipendenti. Fornisce un modo per le aziende di verificare che le chiavi utilizzate siano quelle emesse dall'azienda.
• Riconoscimento di più utenti: Alcuni autenticatori possono riconoscere più utenti. CTAP 2.1 fornisce un modo per questi autenticatori di indicare quale utente è stato riconosciuto.
• Compatibilità con le versioni precedenti: CTAP 2.1 è progettato per essere retrocompatibile con CTAP2, garantendo che i dispositivi e le piattaforme che supportano la versione precedente possano ancora funzionare con la nuova.

Dopo aver esaminato le chiavi residenti, non residenti e le diverse versioni di CTAP, analizziamo ora più a fondo il lato della Relying Party e quindi il lato del server WebAuthn.

La flessibilità (ma anche la complessità) di WebAuthn è in gran parte attribuita alle sue impostazioni del server, in particolare all'interno dell'oggetto authenticatorSelection. Questo oggetto guida il client nella selezione dell'autenticatore giusto per il compito.

{
    "rp": {
        "name": "corbado.com",
        "id": "corbado.com"
    },
    "user": {
        "id": "dGVzdefEyMjE",
        "name": "test-username",
        "displayName": "test-username"
    },
    "challenge": "mhanjsapJjCNaN_Ttasdfk1C0DymR-V_w_0UVOPsdfdfJG2ON_FK5-ODtqp33443tgqHzuuDjv-NUUmMAE4hg",
    "pubKeyCredParams": [
        {
            "type": "public-key",
            "alg": -7
        },
        {
            "type": "public-key",
            "alg": -257
        }
    ],
    "timeout": 60000,
    "excludeCredentials": [],
    "authenticatorSelection": {
        "authenticatorAttachment": "platform",
        "residentKey": "preferred",
        "requireResidentKey": false,
        "userVerification": "preferred"
    },
    "attestation": "none",
    "extensions": {
        "credProps": true
    }
}

Questa opzione del server specifica come l'autenticatore è collegato al dispositivo client. Fornisce indicazioni su come l'autenticatore comunica con il client:

Valori possibili

• Platform: Indica che l'autenticatore è collegato alla piattaforma del client e quindi non è rimovibile.
• Cross-platform: Indica che l'autenticatore non è legato alla piattaforma del client e può essere utilizzato su più dispositivi.

Casi d'uso ed esempi

• Platform: Esempi includono uno scanner di impronte digitali integrato in un laptop o un sistema di riconoscimento facciale su un telefono, come Face ID, Touch ID o Windows Hello.
• Cross-platform: Esempi includono chiavi di sicurezza USB (es. YubiKeys), dispositivi Bluetooth o schede NFC.

Nella specifica WebAuthn Level 1, questa opzione del server era chiamata requireResidentKey e poteva assumere i valori booleani true (l'autenticatore deve creare una chiave residente) o false (l'autenticatore deve creare una chiave non residente). WebAuthn Level 2 ha sostituito questa opzione del server con la nuova opzione residentKey:

Valori possibili

• Required: L'autenticatore deve creare una chiave residente (se non è possibile, l'operazione dovrebbe fallire).
• Preferred: L'autenticatore dovrebbe tentare di creare una chiave residente (se non è possibile, dovrebbe creare una chiave non residente).
• Discouraged: L'autenticatore deve creare una chiave non residente (se non è possibile, l'operazione dovrebbe fallire).

Casi d'uso ed esempi

• Required: Ideale per scenari in cui si desidera l'accesso senza nome utente o in cui gli utenti dovrebbero autenticarsi solo da dispositivi precedentemente registrati (aggiungendo un ulteriore livello di sicurezza legando la credenziale dell'utente a un dispositivo specifico).
• Preferred: Adatto per scenari in cui il servizio web desidera fornire la migliore UX di login possibile (tramite chiavi residenti), ma vuole comunque supportare le chiavi non residenti se quelle residenti non sono possibili.
• Discouraged: Un servizio vuole offrire l'autenticazione con passkey e vuole anche garantire che gli utenti possano utilizzare qualsiasi autenticatore, anche quelli senza capacità di archiviazione, senza legare la credenziale a un dispositivo specifico.

La verifica dell'utente si riferisce al processo che garantisce che la persona che interagisce con l'autenticatore sia il proprietario legittimo, tipicamente richiedendo un gesto di autenticazione specifico come l'inserimento di un PIN, la fornitura di un'impronta digitale o l'uso del riconoscimento facciale.

Talvolta la presenza dell'utente (UP) è menzionata o usata in modo simile alla verifica dell'utente, ma presenta alcune differenze. La presenza dell'utente conferma solo che qualcuno — chiunque — è fisicamente presente e interagisce con il dispositivo. Non verifica l'identità di quella persona. Un semplice tocco di una chiave di sicurezza, senza ulteriori controlli di identità, può essere sufficiente per la presenza dell'utente. Per le passkey / WebAuthn, l'utente deve sempre essere presente.

Valori possibili

• Required: L'operazione deve avere la verifica dell'utente.
• Preferred: L'operazione dovrebbe avere la verifica dell'utente se possibile, ma può procedere senza.
• Discouraged: L'operazione non dovrebbe avere la verifica dell'utente.

Casi d'uso ed esempi

• Required: Ideale per applicazioni ad alta sicurezza come il banking o la sanità, dove la verifica dell'identità dell'utente (ad es. tramite impronta digitale o PIN) è cruciale.
• Preferred: Utile per applicazioni generali in cui una maggiore sicurezza è un vantaggio ma non strettamente necessaria.
• Discouraged: Adatto per operazioni a basso rischio o scenari in cui la verifica dell'utente potrebbe essere un inconveniente.

Pattern

• Authenticator attachment: platform
• Resident key: required
• User verification: required

Esempio: Un'applicazione aziendale vuole che i dipendenti accedano senza password sui loro laptop aziendali utilizzando i lettori di impronte digitali integrati. La credenziale è memorizzata sul dispositivo e l'utente deve verificare con un'impronta digitale ogni volta.

Pattern

• Authenticator attachment: cross-platform
• Resident key: required
• User verification: required

Esempio: Un utente registra una chiave di sicurezza (es. YubiKey) per il suo online banking. Può utilizzare questa chiave per autenticarsi su qualsiasi dispositivo fornendo la chiave di sicurezza (es. YubiKey), senza bisogno di inserire un nome utente.

Molte chiavi di sicurezza basate su hardware (es. YubiKeys) hanno limiti di archiviazione intrinseci. Questa limitazione è dovuta alla memoria fisica disponibile sul dispositivo e alle considerazioni di progettazione del produttore.

Esempio: Una YubiKey potrebbe avere la capacità di memorizzare solo 20 chiavi residenti. Una volta raggiunto questo limite, non è possibile aggiungere altre chiavi residenti senza eliminare quelle esistenti.

Soluzione:

• Uso selettivo delle chiavi residenti: Invece di utilizzare chiavi residenti per ogni utente, considerale per ruoli o scenari specifici. Ad esempio, dai la priorità alle chiavi residenti per i ruoli di amministratore o gli utenti con privilegi elevati che richiedono una maggiore sicurezza.
• Educazione dell'utente: Informa gli utenti sui limiti delle loro chiavi di sicurezza (es. YubiKeys). Incoraggiali a passare a dispositivi che possono utilizzare un numero illimitato di chiavi residenti, come laptop o smartphone.

Differenti autenticatori potrebbero gestire le richieste di chiavi residenti in modo diverso. Alcuni potrebbero creare di default una chiave residente anche se non esplicitamente richiesta, mentre altri potrebbero richiedere un'istruzione esplicita.

Il comportamento incoerente per le diverse opzioni del server WebAuthn su diverse piattaforme è un problema serio. Ad esempio, iOS creerà sempre una chiave residente indipendentemente dalle opzioni del server WebAuthn passate, mentre Android richiede un opt-in (ad es. con residentKey: preferred o residentKey: required).

Oltre al comportamento, è ancora peggio che, basandosi sui dati memorizzati lato server, non si possa dire con certezza al 100% se una credenziale memorizzata sia una chiave residente o non residente. Invece, si possono seguire alcuni controlli e restringere il campo (vedi sotto), ma bisogna comunque sperare che il comportamento della credenziale sia conforme a ciò che si crede.

Il motivo è che esiste una raccomandazione WebAuthn di memorizzare informazioni sul tipo di credenziale (chiave residente o non residente) nell'estensione delle proprietà della credenziale (clientExtensionResults.credProps.rk, che è true o false). Tuttavia, fornire queste informazioni alla RP non è garantito poiché tutte le estensioni WebAuthn sono opzionali, ad esempio iOS non le invia (quindi non si sa se si tratta di una chiave residente o non residente).

Durante la nostra ricerca, abbiamo cercato di testare il comportamento su diverse piattaforme e autenticatori (Windows 10, Windows 11, Android 7, Android 13, iOS17, macOS Ventura, YubiKey) con due pagine demo di WebAuthn che forniscono maggiori dettagli sulle credenziali create: https://webauthn.io e https://webauthntest.identitystandards.io/. Quest'ultima offre la possibilità di lavorare con la proprietà legacy requireResidentKey (WebAuthn Level 1) e persino di combinarla con la proprietà residentKey (WebAuthn Level 2). Tuttavia, i risultati non sono stati affidabili (ad es. indicava una chiave non residente per iOS ma l'UI condizionale funzionava chiaramente).

Lo schema di verifica più affidabile che abbiamo trovato è il seguente:

1. Verifica le impostazioni del tuo server WebAuthn per l'attributo "residentKey"
   1. Se "residentKey: required" e una credenziale viene creata con successo -> è una chiave residente
   2. Se "residentKey: preferred" o "residentKey: discouraged", passa al controllo successivo
2. L'estensione credProps.rk è supportata e memorizzata nella credenziale sul server?
   1. Se credProps.rk = true, la credenziale è una chiave residente
   2. Se credProps.rk = false, la credenziale è una chiave non residente
   3. Se credProps è vuoto, il tipo di credenziale è sconosciuto

Come puoi vedere, questo aiuta a restringere il campo, ma l'opzione sconosciuta rimane e non si può determinare il tipo di chiave con il 100% di certezza.

Questo è anche in linea con le scoperte di William Brown di SUSE nel suo ottimo articolo che illustra come le chiavi di sicurezza (es. YubiKeys) potrebbero diventare inutili se le chiavi residenti sono richieste dalle Relying Party (abbiamo esteso la sua tabella):

Nella tabella, si vede per diverse opzioni di chiave residente del server WebAuthn se è stata creata una chiave residente (true), se è stata creata una chiave non residente (false) o se è successo qualcos'altro.

Soluzione:

• Test approfonditi: Prima di implementare, testa la tua implementazione WebAuthn su una vasta gamma di autenticatori popolari per comprenderne il comportamento.
• Impostazioni esplicite del server: Quando configuri il tuo server WebAuthn, sii esplicito nei tuoi requisiti. Se vuoi avere solo passkey, imposta l'opzione residentKey su required (nota: questo potrebbe portare ad altre sfide con autenticatori con capacità limitata di chiavi residenti, vedi sopra).

Se un utente raggiunge il limite di archiviazione sulla sua chiave di sicurezza (es. YubiKey), potrebbe incontrare errori o non essere in grado di registrare nuove credenziali. Questo può portare a confusione e frustrazione.

Soluzione:

• Gestione degli errori elegante: Implementa messaggi di errore chiari che informino l'utente quando la sua chiave di sicurezza (es. YubiKey) è piena e fornisci indicazioni su come risolvere il problema.
• Flussi di lavoro guidati: Offri guide passo-passo o tutorial su come gli utenti possono gestire le loro chiavi residenti, assicurando che possano risolvere i problemi in modo autonomo.

9. Best practice per sviluppatori e product manager

Come avete visto sopra, le impostazioni del server WebAuthn che scegliete possono avere un impatto significativo sull'esperienza utente e sulla sicurezza del vostro processo di autenticazione. È essenziale comprendere le sfumature di queste impostazioni per prendere decisioni informate.

Chiavi residenti vs. non residenti: Se la maggior parte dei vostri utenti accede principalmente al vostro servizio da dispositivi personali come smartphone o laptop, le chiavi residenti sono una scelta adatta. Le chiavi residenti sono memorizzate sul dispositivo stesso e offrono un'esperienza di autenticazione fluida per gli utenti che utilizzano frequentemente lo stesso dispositivo. Tuttavia, per gli utenti che utilizzano chiavi di sicurezza (es. YubiKeys), le chiavi non residenti potrebbero essere più appropriate.

Impostazioni di verifica dell'utente (UV): A seconda del livello di sicurezza che si desidera raggiungere, è possibile decidere quanto rigoroso debba essere il processo di verifica dell'utente. Se si punta a un'alta sicurezza, è consigliabile richiedere un PIN, un'impronta digitale o il riconoscimento facciale (userVerification: preferred o userVerification: required).

Attestazione e affidabilità: L'attestazione permette di verificare l'origine e l'integrità dell'autenticatore. Decidete se volete fidarvi di tutti gli autenticatori o solo di quelli di produttori specifici. Questo può essere cruciale se si trattano dati sensibili e si vuole garantire che vengano utilizzati solo autenticatori affidabili e di alta qualità.

Meccanismi di fallback: Abbiate sempre un meccanismo di fallback. Se un utente perde il proprio autenticatore o se questo non funziona, dovrebbe avere un modo alternativo per accedere al proprio account. Questo potrebbe essere tramite codici di backup, verifica via SMS, magic link via email o altri metodi di autenticazione a più fattori.

Formazione continua: Il panorama delle passkey e di WebAuthn è in continua evoluzione. Rimanete aggiornati sugli ultimi sviluppi, vulnerabilità e patch. Incoraggiate il vostro team di sviluppo a partecipare a workshop, webinar e conferenze relative a passkey e WebAuthn.

Onboarding ed educazione dell'utente: Quando si introduce l'autenticazione con passkey, assicuratevi che i vostri utenti ne comprendano i vantaggi e il funzionamento. Offrite istruzioni chiare durante il processo di registrazione e fornite risorse (come FAQ o video tutorial) per assistere gli utenti nella configurazione e nell'uso delle passkey.

Aderendo a queste best practice, sviluppatori e product manager possono garantire di implementare l'autenticazione con passkey in modo efficace, bilanciando sicurezza ed esperienza utente.

Se volete implementare le passkey per un'adozione di massa nel vostro sito web o app e non avete bisogno di supportare le chiavi di sicurezza (es. YubiKeys), poiché la maggior parte dei vostri utenti utilizzerà semplicemente il proprio smartphone o laptop, raccomandiamo le seguenti impostazioni.

• authenticator: platform
• residentKey: required
• userVerification: required

Vantaggi:

• Poiché tutte le chiavi create sono residenti, la configurazione permette l'UI condizionale, rendendo il vostro login ancora più fluido per gli utenti, che non dovranno ricordare un nome utente.
• Tutti i dispositivi moderni di Apple, Google e Microsoft sono supportati e utilizzano le passkey.

Le impostazioni del server WebAuthn, sebbene complesse, offrono un framework robusto e flessibile per l'autenticazione. Padroneggiare queste impostazioni è cruciale, poiché non si tratta solo di implementare un nuovo standard, ma di migliorare fondamentalmente la sicurezza e l'efficienza dell'autenticazione utente.

In sostanza, comprendere le impostazioni del server WebAuthn è un investimento nella creazione di applicazioni più sicure, efficienti e proiettate al futuro. Con l'evolversi del panorama digitale, essere esperti in tali tecnologie sarà indispensabile. Per rimanere aggiornati, unitevi alla nostra community di passkey o iscrivetevi alla nostra newsletter qui sotto.