Codici QR e Bluetooth per le passkey WebAuthn: Trasporto Ibrido

Le passkey stanno sostituendo sempre di più le password come standard de facto nell'autenticazione degli utenti. A differenza delle password tradizionali, le passkey sono legate a un ecosistema (ad esempio, Portachiavi iCloud, Google Password Manager, Windows Hello o un gestore di password come 1Password o Dashlane); non sono progettate per essere memorizzate, ma sono costruite per integrarsi perfettamente con i tuoi dispositivi, offrendo un'ottima esperienza utente fin da subito.

Immagina di essere lontano dal tuo computer personale, magari a un terminale pubblico o sul portatile di un amico, e di dover accedere al tuo account protetto da passkey. Questo scenario è piuttosto comune e richiede un metodo di autenticazione sicuro ma comodo. Tuttavia, con le passkey, molte persone non sanno cosa fare, poiché la loro passkey non è immediatamente disponibile in questa situazione. Una delle funzionalità delle passkey che ti aiuta in questi casi è la possibilità di utilizzare le tue passkey su più dispositivi tramite l'uso di codici QR e della tecnologia Bluetooth. Questo processo è formalmente noto come trasporto ibrido nella specifica WebAuthn (nelle versioni precedenti della specifica era indicato come cloud-assisted Bluetooth Low Energy caBLE).

Il processo è semplice: hai bisogno di un dispositivo su cui sono memorizzate le tue passkey e che sia in grado di scattare foto, quindi molto probabilmente uno smartphone o un tablet. Questo dispositivo può aprire un tunnel verso il nuovo dispositivo solo per quella singola istanza di autenticazione. Ciò non solo mantiene l'integrità della tua passkey, ma garantisce anche che l'accesso al tuo account su nuovi dispositivi possa essere concesso, indipendentemente da dove ti trovi o dal dispositivo che desideri utilizzare per accedere.

Tuttavia, questa funzionalità di autenticazione multipiattaforma delle passkey è circondata da idee sbagliate e confusione, sia per quanto riguarda la sua utilità che la sua implementazione tecnica. È una cosa che ho notato di nuovo di recente, quando ho partecipato a un meetup locale sulla sicurezza informatica. Con questo articolo, miriamo a svelare le complessità e a fornire raccomandazioni per implementare questo flusso di autenticazione passkey multipiattaforma (trasporto ibrido), assicurandoti di poter offrire la migliore esperienza di accesso ai tuoi utenti.

Le passkey sono una forma di autenticazione utente che sostituisce la tradizionale password con una coppia di chiavi crittografiche pubblica-privata più sicura e comoda. Questa coppia di chiavi è unica per ogni utente e viene utilizzata per verificare l'identità senza il fastidio di ricordare password complesse.

I vantaggi delle passkey sono numerosi rispetto ai loro predecessori, le password. Riducono significativamente il rischio di phishing, poiché non possono essere ingannate per essere condivise con un sito web falso. Inoltre, sono immuni agli attacchi di forza bruta e a dizionario, che sono metodi comuni utilizzati per violare le password. Le passkey sono anche più facili da usare, eliminando la necessità di ricordare o gestire una lunga lista di password.

Le passkey sono sincronizzate in account cloud, come quelli gestiti da Google Password Manager o Apple Portachiavi iCloud (Microsoft con Windows Hello seguirà presto), o quelle memorizzate nei moderni gestori di password pronti per le passkey, come 1Password o Dashlane. Tuttavia, è essenziale sapere che, per impostazione predefinita, le passkey sono legate all'ecosistema e alla rispettiva sincronizzazione dell'account cloud. I sistemi operativi non forniscono un'interfaccia per esportare le chiavi private e nella maggior parte dei dispositivi è presente un componente hardware che fornisce misure di sicurezza aggiuntive per evitare qualsiasi accesso alle chiavi private, ad esempio il Secure Enclave sui dispositivi iOS o il Trusted Platform Module (TPM) sui dispositivi Windows. Solo il fornitore del sistema operativo può sincronizzare le passkey con altri dispositivi in modo crittografato (protetto in ultima analisi dalla biometria, dal passcode o dal PIN dell'utente). Le chiavi private possono essere ripristinate e decrittografate solo utilizzando il passcode/PIN e verranno distrutte in caso di troppi tentativi di accesso non riusciti all'account cloud (ad esempio, Apple introduce un limite di tentativi per prevenire attacchi di forza bruta anche da una posizione privilegiata sul backend cloud; Google fa lo stesso).

Questo design intrinseco significa che se le passkey non vengono sincronizzate come descritto, accedere alle tue passkey su un nuovo dispositivo può rappresentare una sfida. È proprio per questo che esiste il metodo di trasporto ibrido per l'autenticazione passkey multipiattaforma (trasporto ibrido) con codice QR e controllo di prossimità Bluetooth. Fornisce un ponte sicuro per le tue passkey tra i dispositivi senza la necessità di sincronizzarle tramite un account cloud / gestore di password, mantenendo così il principio che le passkey possono rimanere esclusivamente con l'utente.

L'utilizzo dell'autenticazione passkey multipiattaforma (trasporto ibrido) aiuta a superare i problemi tra dispositivi diversi, quando un account è accessibile esclusivamente tramite passkey. Poiché non tutte le passkey sono sincronizzate in account cloud o gestori di password, la necessità di un metodo affidabile per accedere alle passkey su più dispositivi diventa critica, specialmente quando si passa a un nuovo dispositivo o si ha bisogno di accedere su un dispositivo condiviso.

Per facilitare l'autenticazione passkey multipiattaforma (trasporto ibrido), ci sono i seguenti requisiti hardware:

• Supporto WebAuthn: I dispositivi devono supportare WebAuthn. Questo è già presente sul 99% dei dispositivi, secondo la nostra ultima analisi dei dati sulle passkey.
• Fotocamera per la Scansione di Codici QR: I dispositivi avranno bisogno di una fotocamera in grado di scansionare codici QR. La maggior parte degli smartphone moderni è dotata di fotocamere con questa funzionalità. Inoltre, la fotocamera necessita di capacità di scansione QR integrate (che la maggior parte dei dispositivi ha di serie). Se la tua fotocamera non lo supporta, anche uno scanner QR online è una buona opzione. Altrimenti, va bene anche installare un'app per codici QR.
• Capacità Bluetooth: Il Cloud-assisted Bluetooth Low Energy (caBLE) viene utilizzato per stabilire una connessione sicura basata sulla prossimità tra i dispositivi. Le versioni da cercare sono Bluetooth 4.0 o superiori, che abilitano l'estensione caBLE per WebAuthn.
• Connessione Internet: È necessaria una connessione internet stabile su entrambi i dispositivi, poiché lo scambio comporta l'apertura di un tunnel per eseguire passaggi di verifica che richiedono il trasferimento di dati in tempo reale.

Dal punto di vista del software, esistono i seguenti requisiti:

• Configurazione del Server WebAuthn: Ovviamente, è necessario disporre di un server WebAuthn che gestisca le chiavi pubbliche. Ciò comporta anche l'abilitazione dell'account dell'utente a essere collegato a più autenticatori e la configurazione del server per avviare la cerimonia di autenticazione.
• API Web Bluetooth: Per il controllo di prossimità Bluetooth, dovrai accedere all'API Web Bluetooth che attiva le capacità Bluetooth del dispositivo da un browser.
• Requisiti del Sistema Operativo: Si prega di consultare la seguente tabella sul supporto dell'Autenticazione Cross-Device per diversi sistemi operativi a partire da marzo 2025. Autenticatore significa che il dispositivo può fungere da dispositivo che contiene una passkey (nel nostro scenario, lo smartphone). Client significa il dispositivo che crea il codice QR e dove l'utente cerca di accedere (nel nostro scenario, il desktop):

Fonte: passkeys.dev

Il processo per utilizzare l'autenticazione passkey multipiattaforma (trasporto ibrido) tramite codice QR è il seguente:

Il codice QR per l'autenticazione passkey multipiattaforma (trasporto ibrido) viene generato quando un utente tenta di accedere a un servizio su un dispositivo in cui la passkey registrata non è presente, ma il servizio sa che l'utente dovrebbe avere una passkey. Tipicamente, un pulsante "Scansiona codice QR" o una call-to-action simile è fornita all'interno dell'interfaccia di autenticazione.

Su richiesta dell'utente, il dispositivo avvia la generazione di un codice QR. Questo codice QR codifica un identificatore di sessione unico e a tempo. Questo identificatore è legato a una sessione che il server di autenticazione mantiene temporaneamente, in attesa del completamento del processo di autenticazione.

L'utente scansiona questo codice QR con un dispositivo in cui è disponibile la sua passkey. Le misure di sicurezza includono:

• Uso singolo: L'identificatore di sessione all'interno del codice QR è valido per un singolo uso, prevenendo attacchi di replay.
• Crittografia: Tutti i dati all'interno del codice QR sono crittografati, garantendo che qualsiasi comunicazione intercettata non possa essere decifrata da parti non autorizzate.

Il codice QR scansionato contiene un URI specifico con lo schema FIDO, ad esempio: FIDO:/07824133892604070278923969472008301099476228966286113051476699183587 6383562063181103169246410435938367110394959927031730060360967994421 343201235185697538107096654083332

La scansione del codice QR fa sì che il secondo dispositivo dell'utente (ad es. smartphone o tablet) interpreti l'URI FIDO e comunichi con il server di autenticazione, inviando un segnale che l'utente sta tentando di autenticarsi tramite un nuovo dispositivo (ad es. il portatile dell'amico). Questa azione spinge il server a generare una sfida crittografica, unica per questo tentativo di autenticazione.

La sfida viene inviata al secondo dispositivo dell'utente (ad es. smartphone o tablet), dove è memorizzata la sua passkey. Il dispositivo crea quindi una firma digitale utilizzando la chiave privata associata alla passkey, senza che la chiave privata lasci mai il dispositivo (ad es. smartphone o tablet). La sfida firmata (firma) viene quindi inviata al server attraverso un tunnel sicuro e crittografato su Internet, verificando l'integrità e l'origine del tentativo di autenticazione.

Il server convalida la firma utilizzando la chiave pubblica corrispondente già associata all'account dell'utente. In caso di convalida riuscita, il server conferma l'autenticazione, consentendo all'utente di accedere al servizio sul nuovo dispositivo.

Alcuni aspetti importanti di privacy e sicurezza da considerare:

• Nessuno Scambio di Dati Bluetooth, solo Internet: È importante notare che in questa autenticazione passkey multipiattaforma (trasporto ibrido) basata su codice QR, il Bluetooth non è coinvolto nello scambio di dati. Questo processo si basa interamente su una connessione Internet per la trasmissione di dati crittografati tra i dispositivi e il server. Tuttavia, il Bluetooth viene utilizzato per un controllo di prossimità dei due dispositivi.
• Le Chiavi Private non Lasciano il Dispositivo: Durante tutto questo processo, le chiavi private dell'utente rimangono al sicuro sul loro dispositivo.
• Nessuna Esposizione di Dati Sensibili: Nessuna informazione sensibile sulla passkey o chiavi private viene trasferita o esposta durante il processo di autenticazione.
• Crittografia Asimmetrica: Il meccanismo di sfida-risposta garantisce che ciò che viene inviato sono semplicemente versioni firmate e non riutilizzabili di sfide che non possono essere sfruttate per accessi non autorizzati.

Aderendo a questi protocolli tecnici e di sicurezza, il metodo del codice QR per l'autenticazione passkey multipiattaforma (trasporto ibrido) mantiene un elevato standard di sicurezza fornendo al contempo un modo comodo per gli utenti di autenticare le proprie identità su nuovi dispositivi.

Oltre al processo di scansione del codice QR, c'è anche il controllo di prossimità tramite Bluetooth (caBLE). Essere sicuri che il client e l'autenticatore siano fisicamente vicini è uno dei maggiori vantaggi del protocollo WebAuthn. Maggiori dettagli sul funzionamento interno di questo processo sono descritti di seguito:

Bluetooth Low Energy (BLE) è una tecnologia di comunicazione wireless progettata per lo scambio di dati a corto raggio. Svolge un ruolo fondamentale nel confermare la prossimità fisica dei dispositivi durante il processo di autenticazione.

caBLE è un protocollo che facilita il trasferimento sicuro di informazioni di autenticazione tra dispositivi utilizzando il BLE. Quando si utilizza caBLE per l'autenticazione passkey multipiattaforma (trasporto ibrido), il dispositivo che detiene la passkey conferma la prossimità del dispositivo richiedente tramite segnali BLE. Una volta verificata la prossimità, il processo di autenticazione procede, sfruttando il BLE per una comunicazione locale e sicura.

L'esperienza utente è migliorata poiché questo metodo richiede tipicamente meno interazione diretta da parte dell'utente; i dispositivi in stretta prossimità fisica si rilevano automaticamente. Per la sicurezza, caBLE offre un vantaggio significativo: garantisce che il processo di autenticazione venga eseguito solo quando i due dispositivi sono vicini, impedendo agli aggressori remoti di avviare il processo di autenticazione.

Immagina di ricevere un codice QR che reindirizza a un sito dannoso. Se l'autenticazione viene eseguita tramite questo codice QR, c'è il rischio che la sessione o il cookie possano essere dirottati. Il BLE aggira questo problema non basandosi su una scansione visiva, ma sulla presenza fisica dei dispositivi. Questo controllo di prossimità minimizza il rischio di attacchi man-in-the-middle, poiché il controllo di prossimità non avviene su Internet o su un mezzo visivo.

A differenza di altri metodi, caBLE non scambia effettivamente dati di autenticazione come le passkey. Invece, utilizza il BLE come canale di conferma per stabilire che i dispositivi sono fisicamente vicini. Questo controllo è progettato per essere parte di un processo di autenticazione a più fattori in cui la prossimità BLE è uno dei fattori, garantendo che anche se altri fattori sono compromessi, senza la prossimità fisica, l'accesso non viene concesso.

Integrando il protocollo caBLE, gli sviluppatori possono offrire un metodo sicuro e facile da usare per l'autenticazione passkey multipiattaforma (trasporto ibrido) che migliora la sicurezza complessiva del processo di autenticazione. Il controllo di prossimità aggiunge un ulteriore livello di protezione che è semplice per gli utenti e tuttavia protegge efficacemente da alcuni tipi di attacchi informatici sofisticati.

Esistono i seguenti vantaggi di questo metodo di autenticazione passkey multipiattaforma (trasporto ibrido):

L'autenticazione passkey multipiattaforma tramite codice QR e Bluetooth (trasporto ibrido) è un modo per migliorare l'UX in scenari multipiattaforma rispetto a non offrire alcuna possibilità. Tuttavia, il flusso utente è assolutamente nuovo per la maggior parte degli utenti e non ci aspettiamo che molti utenti non tecnici capiscano cosa sta succedendo la prima volta che incontrano questo flusso. L'unica somiglianza nell'introdurre il flusso del codice QR può essere con i flussi di accesso per, ad esempio, WhatsApp Web o Discord, dove vengono utilizzati i codici QR (anche se qui la funzionalità è diversa). Quindi, il processo di autenticazione passkey multipiattaforma analizzato tramite codice QR / Bluetooth (trasporto ibrido) minimizza lo sforzo dell'utente nello scenario multipiattaforma, poiché non è necessario inserire manualmente alcuna credenziale, ma il flusso complessivo è ancora sconosciuto alla maggior parte degli utenti.

La sicurezza dell'autenticazione passkey multipiattaforma (trasporto ibrido) è rafforzata da tecniche crittografiche avanzate. Quando un codice QR viene scansionato o viene stabilita una connessione Bluetooth per l'autenticazione, le sfide e le risposte crittografiche assicurano che solo il dispositivo previsto possa completare con successo il processo di autenticazione.

I controlli di prossimità tramite Bluetooth aggiungono un ulteriore livello di sicurezza, confermando che il tentativo di autenticazione viene effettuato da qualcuno con accesso fisico al dispositivo secondario.

Durante il processo di autenticazione multipiattaforma (trasporto ibrido), le passkey non vengono mai memorizzate temporaneamente su dispositivi o server intermedi, il che previene il rischio che le passkey vengano intercettate o trapelate durante il processo di trasferimento. L'autenticazione avviene in tempo reale e la passkey rimane legata al dispositivo primario dell'utente, preservandone l'integrità.

I metodi di autenticazione tramite codice QR e Bluetooth forniscono intrinsecamente protezione contro il phishing. È meno probabile che gli utenti vengano ingannati a fornire una passkey per un sito dannoso perché il processo di autenticazione richiede azioni fisiche specifiche per i dispositivi fidati dell'utente.

Il processo di scansione di un codice QR o di connessione tramite Bluetooth avviene tipicamente in un ambiente fidato, riducendo la possibilità che gli utenti compromettano involontariamente le proprie credenziali.

Esistono i seguenti svantaggi di questo metodo di autenticazione passkey multipiattaforma (trasporto ibrido):

L'introduzione di qualsiasi nuova tecnologia può portare a confusione da parte dell'utente, specialmente se gli utenti non sono esperti di tecnologia. L'autenticazione passkey multipiattaforma tramite codice QR e Bluetooth (trasporto ibrido) è un cambiamento significativo rispetto ai metodi di autenticazione tradizionali, e alcuni utenti potrebbero trovare il nuovo processo difficile da comprendere, portando potenzialmente a un tasso di adozione più lento. Tuttavia, ci aspettiamo che gli utenti alla fine si abituino, quindi il cambiamento potrebbe essere più difficile all'inizio e diventerà più fluido e accettato nel tempo.

Il successo dell'autenticazione passkey multipiattaforma (trasporto ibrido) dipende fortemente dal fatto che il dispositivo dell'utente abbia le capacità necessarie, come una fotocamera in grado di scansionare codici QR e la funzionalità Bluetooth. Gli utenti con dispositivi più vecchi che non dispongono di queste funzionalità non saranno in grado di sfruttare l'autenticazione passkey multipiattaforma (trasporto ibrido), creando un divario digitale basato su limitazioni hardware.

Il comportamento dell'utente può essere imprevedibile e la dipendenza dagli utenti per eseguire azioni specifiche come la scansione di un codice QR o l'abilitazione del Bluetooth può introdurre errori da parte dell'utente. Ad esempio, il Bluetooth può talvolta essere visto come una sfida per l'UX a causa di problemi di accoppiamento, problemi di rilevamento e una generale sfiducia degli utenti verso le tecnologie wireless per transazioni sicure.

Gli sviluppatori affrontano il compito di aggiornare e mantenere costantemente i sistemi per supportare i più recenti metodi di autenticazione. L'integrazione dell'autenticazione passkey multipiattaforma (trasporto ibrido) nei sistemi esistenti richiede agli sviluppatori di rimanere al passo con i nuovi standard, adottare nuove API e garantire la compatibilità con le versioni precedenti, il che può richiedere molte risorse e tempo.

Per ogni nuovo dispositivo o richiesta di accesso successiva, è necessario creare una nuova passkey se non si utilizza un account cloud sincronizzato come Portachiavi iCloud o un gestore di password. Ciò potrebbe aggiungere complessità all'esperienza utente e creare frustrazione se gli utenti non hanno familiarità con il processo o se non è reso intuitivo.

C'è una necessità intrinseca di educare gli utenti quando si implementano nuovi metodi di sicurezza come l'autenticazione passkey multipiattaforma (trasporto ibrido). Garantire che gli utenti capiscano come utilizzare i codici QR e il Bluetooth in modo sicuro richiede una comunicazione chiara e possibilmente un ampio supporto clienti.

Sebbene l'autenticazione passkey multipiattaforma tramite codice QR e Bluetooth (trasporto ibrido) rappresenti un progresso significativo nella tecnologia di autenticazione, questi potenziali svantaggi evidenziano la necessità di un design user-friendly, sistemi di supporto robusti e una transizione graduale e ben comunicata dai metodi tradizionali a quelli innovativi. Come per ogni cambiamento tecnologico, bilanciare i benefici dell'innovazione con le sue sfide sarà la chiave per un'implementazione di successo e un'ampia accettazione da parte degli utenti.

Come disclaimer: nei seguenti test ignoreremo le chiavi di sicurezza hardware (ad es. YubiKey) e utilizzeremo solo autenticatori di piattaforma integrati nei dispositivi (ad es. Face ID, Touch ID, Windows Hello). In caso di chiavi di sicurezza hardware (ad es. YubiKey), i valori per i trasporti sarebbero, ad esempio, usb o nfc.

Stiamo utilizzando le seguenti combinazioni di dispositivo/browser e il Passkeys Debugger per testare il comportamento. Android non è considerato poiché Android non può fungere da client di autenticazione multipiattaforma (trasporto ibrido) (vedi tabella sopra):

Per testare il comportamento, creiamo per ogni combinazione una nuova passkey con le seguenti proprietà:

• userName: alex muller (nessuna influenza in questo test)
• authenticatorAttachment: platform (poiché vogliamo escludere le chiavi di sicurezza hardware come le YubiKey)
• residentKey: preferred (nessuna influenza in questo test)
• userVerification: preferred (nessuna influenza in questo test)
• attestation: none (nessuna influenza in questo test)
• hints: empty (vedi spiegazione sotto)
• usePRF: no (nessuna influenza in questo test)

Dopo la creazione riuscita della passkey, modifichiamo l'input della proprietà allowCredentials del server WebAuthn e avviamo una richiesta di accesso. Vogliamo simulare una passkey eliminata sul dispositivo in cui abbiamo creato la passkey, in modo che il dispositivo/browser cerchi un altro dispositivo che possa fornire una passkey tramite codice QR / Bluetooth. Pertanto, cambiamo il credential ID e assegniamo il valore CHANGED-ID, in modo che la corrispondenza fallisca. Inoltre, cambiamo la proprietà transports di una credenziale WebAuthn in allowCredentials e assegniamo per ogni combinazione di dispositivo/browser i seguenti valori:

1. transports: [internal, hybrid]: Le passkey possono essere utilizzate dall'autenticatore di piattaforma (ad es. Face ID, Touch ID, Windows Hello) o tramite autenticazione multipiattaforma
2. transports: [internal]: Le passkey possono essere utilizzate dall'autenticatore di piattaforma (ad es. Face ID, Touch ID, Windows Hello)
3. Nessuna proprietà transports impostata: comportamento predefinito che non impone restrizioni

Nel sito di test WebAuthn, è presente anche la nuova funzionalità WebAuthn Level 3 per gli hint degli user agent. Questa funzionalità può migliorare l'esperienza utente se la relying party ha determinate ipotesi su come la richiesta di accesso può essere completata nel modo più user-friendly. In questo test, abbiamo ignorato questa funzionalità poiché non è ancora stata distribuita. Si prega di consultare le specifiche per maggiori dettagli.

Come previsto, nessuna passkey locale corrisponde, quindi viene suggerito di scansionare il codice QR e utilizzare la passkey su un altro dispositivo (poiché il sistema sa che esiste una passkey per questo utente).

In modo piuttosto confuso, il codice QR viene visualizzato anche qui, anche se consentiamo solo credenziali interne. Non siamo riusciti a trovare una ragione valida per questo comportamento.

Nessuna passkey locale corrisponde, quindi viene suggerito di scansionare il codice QR o utilizzare una chiave di sicurezza hardware (ad es. YubiKey) / autenticatore multipiattaforma / autenticatore roaming.

Per qualche motivo, parti della modale appaiono in tedesco, che è una delle lingue installate.

Come previsto, sono consentite tutte le forme di autenticazione con passkey: tramite Windows Hello, tramite codice QR, tramite dispositivi noti e tramite chiavi di sicurezza hardware.

Come previsto, nessuna passkey locale corrisponde, quindi viene suggerito di scansionare il codice QR e utilizzare la passkey su un altro dispositivo (poiché il sistema sa che esiste una passkey per questo utente).

In modo piuttosto confuso, il codice QR viene visualizzato anche qui, anche se consentiamo solo credenziali interne. Non siamo riusciti a trovare una ragione valida per questo comportamento.

Nessuna passkey locale corrisponde, quindi viene suggerito di scansionare il codice QR o utilizzare una chiave di sicurezza hardware (ad es. YubiKey) / autenticatore multipiattaforma / autenticatore roaming.

Per qualche motivo, parti della modale appaiono in tedesco, che è una delle lingue installate.

Come previsto, sono consentite tutte le forme di autenticazione con passkey: tramite Windows Hello, tramite codice QR, tramite dispositivi noti e tramite chiavi di sicurezza hardware.

Durante la creazione della passkey, abbiamo ricevuto il seguente errore (è stata comunque creata una passkey):

errore: TypeError: 'toJSON' chiamato su un oggetto che non implementa l'interfaccia PublicKeyCredential.

Come previsto, nessuna passkey locale corrisponde, quindi viene suggerito di scansionare il codice QR e utilizzare la passkey su un altro dispositivo (poiché il sistema sa che esiste una passkey per questo utente).

In modo piuttosto confuso, il codice QR viene visualizzato anche qui, anche se consentiamo solo credenziali interne. Non siamo riusciti a trovare una ragione valida per questo comportamento.

Nessuna passkey locale corrisponde, quindi viene suggerito di scansionare il codice QR o utilizzare una chiave di sicurezza hardware (ad es. YubiKey) / autenticatore multipiattaforma / autenticatore roaming.

Per qualche motivo, parti della modale appaiono in tedesco, che è una delle lingue installate.

Come previsto, sono consentite tutte le forme di autenticazione con passkey: tramite Windows Hello, tramite codice QR, tramite dispositivi noti e tramite chiavi di sicurezza hardware.

Come previsto, nessuna passkey locale corrisponde, quindi viene suggerito di scansionare il codice QR e utilizzare la passkey su un altro dispositivo (poiché il sistema sa che esiste una passkey per questo utente). Inoltre, è possibile selezionare direttamente uno dei dispositivi noti per utilizzare una passkey da lì.

La modale è piuttosto diversa dalla sua controparte su Windows in Chrome 119.

Questo è un comportamento previsto, poiché consentiamo di utilizzare solo passkey interne ma non riusciamo a trovare una credenziale interna sul dispositivo (non siamo autorizzati a utilizzare passkey ibride). L'autenticazione con passkey fallisce in questo passaggio e nelle implementazioni reali sarebbe necessario fornire un metodo di autenticazione di fallback.

Nessuna passkey locale corrisponde, quindi viene suggerito di scansionare il codice QR o utilizzare una chiave di sicurezza hardware (ad es. YubiKey) / autenticatore multipiattaforma / autenticatore roaming. Inoltre, è possibile selezionare direttamente uno dei dispositivi noti per utilizzare una passkey da lì.

La modale è piuttosto diversa dalla sua controparte su Windows in Chrome 119.

Come previsto, sono consentite tutte le forme di autenticazione con passkey: tramite Touch ID, tramite codice QR, tramite dispositivi noti e tramite chiavi di sicurezza hardware.

Come previsto, nessuna passkey locale corrisponde, quindi viene suggerito di scansionare il codice QR e utilizzare la passkey su un altro dispositivo (poiché il sistema sa che esiste una passkey per questo utente).

In modo piuttosto confuso, il codice QR viene visualizzato anche qui, anche se consentiamo solo credenziali interne. Non siamo riusciti a trovare una ragione valida per questo comportamento.

Nessuna passkey locale corrisponde, quindi viene suggerito di scansionare il codice QR o utilizzare una chiave di sicurezza hardware (ad es. YubiKey) / autenticatore multipiattaforma / autenticatore roaming.

Come previsto, la maggior parte delle forme di autenticazione con passkey sono consentite: tramite Touch ID, tramite codice QR e tramite chiavi di sicurezza hardware. Per qualche motivo i dispositivi noti non vengono visualizzati.

Come previsto, nessuna passkey locale corrisponde, quindi viene suggerito di scansionare il codice QR e utilizzare la passkey su un altro dispositivo (poiché il sistema sa che esiste una passkey per questo utente).

In modo piuttosto confuso, il codice QR viene visualizzato anche qui, anche se consentiamo solo credenziali interne. Non siamo riusciti a trovare una ragione valida per questo comportamento.

Nessuna passkey locale corrisponde, quindi viene suggerito di scansionare il codice QR o utilizzare una chiave di sicurezza hardware (ad es. YubiKey) / autenticatore multipiattaforma / autenticatore roaming.

Come previsto, la maggior parte delle forme di autenticazione con passkey sono consentite: tramite Face ID, tramite codice QR e tramite chiavi di sicurezza hardware. Per qualche motivo i dispositivi noti non vengono visualizzati.

Come previsto, nessuna passkey locale corrisponde, quindi viene suggerito di scansionare il codice QR e utilizzare la passkey su un altro dispositivo (poiché il sistema sa che esiste una passkey per questo utente).

In modo piuttosto confuso, il codice QR viene visualizzato anche qui, anche se consentiamo solo credenziali interne. Non siamo riusciti a trovare una ragione valida per questo comportamento.

Nessuna passkey locale corrisponde, quindi viene suggerito di scansionare il codice QR o utilizzare una chiave di sicurezza hardware (ad es. YubiKey) / autenticatore multipiattaforma / autenticatore roaming.

Come previsto, la maggior parte delle forme di autenticazione con passkey sono consentite: tramite Face ID, tramite codice QR e tramite chiavi di sicurezza hardware. Per qualche motivo i dispositivi noti non vengono visualizzati.

Di seguito, per i dispositivi Windows 10, abbiamo deciso di andare un livello oltre e analizzare come si presenta il comportamento se il Bluetooth è disabilitato o non disponibile su una macchina Windows 10 in generale. In particolare per i dispositivi desktop più vecchi, questo è ancora uno scenario molto comune poiché questi dispositivi spesso non hanno un modulo Bluetooth, rendendo impossibile l'autenticazione multipiattaforma tramite codice QR e Bluetooth.

8.8.1.1 transports: [internal, hybrid]

Come previsto, nessuna passkey locale corrisponde, quindi viene suggerito di utilizzare la passkey su un altro dispositivo (poiché il sistema sa che esiste una passkey per questo utente - primo screenshot) o di scegliere di scansionare il codice QR (secondo screenshot).

8.8.1.2 transports: [internal]

In modo piuttosto confuso, viene richiesto di inserire il codice PIN di Windows Hello (o l'impronta digitale / scansione del volto se configurata sul dispositivo), anche se abbiamo cambiato il credential ID (quindi in realtà non dovrebbe trovare la credenziale poiché non è specificata nella proprietà allowCredentials). Tuttavia, dopo aver inviato il codice PIN di Windows Hello, viene generato un errore: "NotAllowedError: L'operazione è scaduta o non è stata consentita. Vedi: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations-client". Dal punto di vista dell'utente, questo è un comportamento piuttosto confuso ma ha senso poiché potrebbe fornire informazioni sulle passkey dell'utente senza il suo consenso.

8.8.1.3 Nessuna proprietà transports impostata

Nessuna passkey locale corrisponde, quindi viene suggerito di scansionare il codice QR o utilizzare una chiave di sicurezza hardware (ad es. YubiKey) / autenticatore multipiattaforma / autenticatore roaming.

8.8.1.4 allowCredentials vuoto

Come previsto, sono consentite tutte le forme di autenticazione con passkey: tramite Windows Hello, tramite codice QR, tramite dispositivi noti e tramite chiavi di sicurezza hardware.

8.8.2.1 transports: [internal, hybrid]

Questo è un messaggio davvero confuso per gli utenti, poiché non viene dichiarato esplicitamente cosa dovrebbero fare e come possono autenticarsi. L'unica opzione che hanno è fare clic su "Annulla", rendendo questo scenario un vicolo cieco.

8.8.2.2 transports: [internal]

Questo comportamento è lo stesso del caso in cui il Bluetooth è abilitato. È molto confuso che all'utente venga richiesto di inserire il codice PIN di Windows Hello (o l'impronta digitale / scansione del volto se configurata sul dispositivo), anche se abbiamo cambiato il credential ID (quindi in realtà non dovrebbe trovare la credenziale poiché non è specificata nella proprietà allowCredentials). Tuttavia, dopo aver inviato il codice PIN di Windows Hello, viene generato un errore: "NotAllowedError: L'operazione è scaduta o non è stata consentita. Vedi: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations-client". Dal punto di vista dell'utente, questo è un comportamento piuttosto confuso ma ha senso poiché potrebbe fornire informazioni sulle passkey dell'utente senza il suo consenso.

8.8.2.3 Nessuna proprietà transports impostata

Nessuna passkey locale corrisponde, quindi l'unica opzione che hai è utilizzare una chiave di sicurezza hardware (ad es. YubiKey) / autenticatore multipiattaforma / autenticatore roaming.

8.8.2.4 allowCredentials vuoto

L'autenticazione con passkey è possibile solo tramite Windows Hello e chiavi di sicurezza hardware.

8.9.1.1 transports: [internal, hybrid]

Come previsto, nessuna passkey locale corrisponde, quindi viene suggerito di scansionare il codice QR e utilizzare la passkey su un altro dispositivo (poiché il sistema sa che esiste una passkey per questo utente).

8.9.1.2 transports: [internal]

In modo piuttosto confuso, viene richiesto di inserire il codice PIN di Windows Hello (o l'impronta digitale / scansione del volto se configurata sul dispositivo), anche se abbiamo cambiato il credential ID (quindi in realtà non dovrebbe trovare la credenziale poiché non è specificata nella proprietà allowCredentials). Tuttavia, dopo aver inviato il codice PIN di Windows Hello, viene generato un errore: "NotAllowedError: L'operazione è scaduta o non è stata consentita. Vedi: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations-client". Dal punto di vista dell'utente, questo è un comportamento piuttosto confuso ma ha senso poiché potrebbe fornire informazioni sulle passkey dell'utente senza il suo consenso.

8.9.1.3 Nessuna proprietà transports impostata

Nessuna passkey locale corrisponde, quindi viene suggerito di scansionare il codice QR o utilizzare una chiave di sicurezza hardware (ad es. YubiKey) / autenticatore multipiattaforma / autenticatore roaming.

8.9.1.4 allowCredentials vuoto

Come previsto, sono consentite tutte le forme di autenticazione con passkey: tramite Windows Hello, tramite codice QR e tramite chiavi di sicurezza hardware. Per qualche motivo, i dispositivi noti non vengono visualizzati.

8.9.2.1 transports: [internal, hybrid]

Questo è un messaggio davvero confuso per gli utenti, poiché non viene dichiarato esplicitamente cosa dovrebbero fare e come possono autenticarsi. L'unica opzione che hanno è fare clic su "Annulla", rendendo questo scenario un vicolo cieco.

8.9.2.2 transports: [internal]

Questo comportamento è lo stesso del caso in cui il Bluetooth è abilitato. È molto confuso che all'utente venga richiesto di inserire il codice PIN di Windows Hello (o l'impronta digitale / scansione del volto se configurata sul dispositivo), anche se abbiamo cambiato il credential ID (quindi in realtà non dovrebbe trovare la credenziale poiché non è specificata nella proprietà allowCredentials). Tuttavia, dopo aver inviato il codice PIN di Windows Hello, viene generato un errore: "NotAllowedError: L'operazione è scaduta o non è stata consentita. Vedi: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations-client". Dal punto di vista dell'utente, questo è un comportamento piuttosto confuso ma ha senso poiché potrebbe fornire informazioni sulle passkey dell'utente senza il suo consenso.

8.9.2.3 Nessuna proprietà transports impostata

Nessuna passkey locale corrisponde, quindi l'unica opzione che hai è utilizzare una chiave di sicurezza hardware (ad es. YubiKey) / autenticatore multipiattaforma / autenticatore roaming.

8.9.2.4 allowCredentials vuoto

L'autenticazione con passkey è possibile solo tramite Windows Hello e chiavi di sicurezza hardware.

8.10.1.1 transports: [internal, hybrid]

Come previsto, nessuna passkey locale corrisponde, quindi viene suggerito di scansionare il codice QR e utilizzare la passkey su un altro dispositivo (poiché il sistema sa che esiste una passkey per questo utente).

8.10.1.2 transports: [internal]

In modo piuttosto confuso, viene richiesto di inserire il codice PIN di Windows Hello (o l'impronta digitale / scansione del volto se configurata sul dispositivo), anche se abbiamo cambiato il credential ID (quindi in realtà non dovrebbe trovare la credenziale poiché non è specificata nella proprietà allowCredentials). Tuttavia, dopo aver inviato il codice PIN di Windows Hello, viene generato un errore: "NotAllowedError: L'operazione è scaduta o non è stata consentita. Vedi: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations-client". Dal punto di vista dell'utente, questo è un comportamento piuttosto confuso ma ha senso poiché potrebbe fornire informazioni sulle passkey dell'utente senza il suo consenso.

8.10.1.3 Nessuna proprietà transports impostata

Nessuna passkey locale corrisponde, quindi viene suggerito di scansionare il codice QR o utilizzare una chiave di sicurezza hardware (ad es. YubiKey) / autenticatore multipiattaforma / autenticatore roaming.

8.10.1.4 allowCredentials vuoto

Come previsto, sono consentite tutte le forme di autenticazione con passkey: tramite Windows Hello, tramite codice QR e tramite chiavi di sicurezza hardware. Per qualche motivo, i dispositivi noti non vengono visualizzati.

8.10.2.1 transports: [internal, hybrid]

Questo è un messaggio davvero confuso per gli utenti, poiché non viene dichiarato esplicitamente cosa dovrebbero fare e come possono autenticarsi. L'unica opzione che hanno è fare clic su "Annulla", rendendo questo scenario un vicolo cieco. Per qualche motivo, parti della modale di Sicurezza di Windows sono visualizzate anche in tedesco (una seconda lingua installata su questo dispositivo).

8.10.2.2 transports: [internal]

Questo comportamento è lo stesso del caso in cui il Bluetooth è abilitato. È molto confuso che all'utente venga richiesto di inserire il codice PIN di Windows Hello (o l'impronta digitale / scansione del volto se configurata sul dispositivo), anche se abbiamo cambiato il credential ID (quindi in realtà non dovrebbe trovare la credenziale poiché non è specificata nella proprietà allowCredentials). Tuttavia, dopo aver inviato il codice PIN di Windows Hello, viene generato un errore: "NotAllowedError: L'operazione è scaduta o non è stata consentita. Vedi: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations-client". Dal punto di vista dell'utente, questo è un comportamento piuttosto confuso ma ha senso poiché potrebbe fornire informazioni sulle passkey dell'utente senza il suo consenso.

8.10.2.3 Nessuna proprietà transports impostata

Nessuna passkey locale corrisponde, quindi l'unica opzione che hai è utilizzare una chiave di sicurezza hardware (ad es. YubiKey) / autenticatore multipiattaforma / autenticatore roaming.

8.10.2.4 allowCredentials vuoto

L'autenticazione con passkey è possibile solo tramite Windows Hello e chiavi di sicurezza hardware.

8.11.1.1 transports: [internal, hybrid]

Come previsto, nessuna passkey locale corrisponde, quindi viene suggerito di scansionare il codice QR e utilizzare la passkey su un altro dispositivo (poiché il sistema sa che esiste una passkey per questo utente).

8.11.1.2 transports: [internal]

In modo piuttosto confuso, viene richiesto di inserire il codice PIN di Windows Hello (o l'impronta digitale / scansione del volto se configurata sul dispositivo), anche se abbiamo cambiato il credential ID (quindi in realtà non dovrebbe trovare la credenziale poiché non è specificata nella proprietà allowCredentials). Tuttavia, dopo aver inviato il codice PIN di Windows Hello, viene generato un errore: "NotAllowedError: L'operazione è scaduta o non è stata consentita. Vedi: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations-client". Dal punto di vista dell'utente, questo è un comportamento piuttosto confuso ma ha senso poiché potrebbe fornire informazioni sulle passkey dell'utente senza il suo consenso.

8.11.1.3 Nessuna proprietà transports impostata

Nessuna passkey locale corrisponde, quindi viene suggerito di scansionare il codice QR o utilizzare una chiave di sicurezza hardware (ad es. YubiKey) / autenticatore multipiattaforma / autenticatore roaming.

8.11.1.4 allowCredentials vuoto

Come previsto, sono consentite tutte le forme di autenticazione con passkey: tramite Windows Hello, tramite codice QR e tramite chiavi di sicurezza hardware. Per qualche motivo, i dispositivi noti non vengono visualizzati.

8.11.2.1 transports: [internal, hybrid]

Questo è un messaggio davvero confuso per gli utenti, poiché non viene dichiarato esplicitamente cosa dovrebbero fare e come possono autenticarsi. L'unica opzione che hanno è fare clic su "Annulla", rendendo questo scenario un vicolo cieco.

8.11.2.2 transports: [internal]

Questo comportamento è lo stesso del caso in cui il Bluetooth è abilitato. È molto confuso che all'utente venga richiesto di inserire il codice PIN di Windows Hello (o l'impronta digitale / scansione del volto se configurata sul dispositivo), anche se abbiamo cambiato il credential ID (quindi in realtà non dovrebbe trovare la credenziale poiché non è specificata nella proprietà allowCredentials). Tuttavia, dopo aver inviato il codice PIN di Windows Hello, viene generato un errore: "NotAllowedError: L'operazione è scaduta o non è stata consentita. Vedi: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations-client". Dal punto di vista dell'utente, questo è un comportamento piuttosto confuso ma ha senso poiché potrebbe fornire informazioni sulle passkey dell'utente senza il suo consenso.

8.11.2.3 Nessuna proprietà transports impostata

Nessuna passkey locale corrisponde, quindi l'unica opzione che hai è utilizzare una chiave di sicurezza hardware (ad es. YubiKey) / autenticatore multipiattaforma / autenticatore roaming.

8.11.2.4 allowCredentials vuoto

L'autenticazione con passkey è possibile solo tramite Windows Hello e chiavi di sicurezza hardware.

• Utilizzare librerie e framework che astraggono alcune delle complessità della pura API WebAuthn.
• Considerare gli scenari di autenticazione multipiattaforma fin dall'inizio per garantire che un'ampia base di utenti possa beneficiare della vostra implementazione di passkey. A seconda delle vostre scelte di progettazione, potete anche offrire metodi di accesso alternativi in questi scenari.
• Sviluppare meccanismi di fallback per scenari in cui l'autenticazione multipiattaforma con passkey (trasporto ibrido) potrebbe non essere possibile a causa di limitazioni del dispositivo.
• La più grande decisione di progettazione è decidere se si desidera promuovere l'autenticazione passkey multipiattaforma tramite codice QR / Bluetooth (trasporto ibrido) e renderla un metodo prominente per l'autenticazione con passkey o utilizzare degli hint per non promuoverla attivamente. In quest'ultimo caso, si cerca sempre di utilizzare immediatamente le passkey memorizzate internamente e solo se non viene trovata alcuna passkey interna, viene visualizzato un codice QR per l'autenticazione multipiattaforma (trasporto ibrido). Questo deve essere definito nelle opzioni del vostro server WebAuthn nelle proprietà excludeCredentials e allowCredentials. Nella proprietà excludeCredentials del vostro server WebAuthn, potete vedere le informazioni di trasporto sulle credenziali già create. Nella proprietà allowCredentials, potete specificare il comportamento nel processo di accesso (vedi test sopra).
• Inoltre, non è possibile impedire completamente l'autenticazione passkey multipiattaforma (trasporto ibrido) (vedi i test sopra con transports: [internal]), quindi è necessario essere preparati al fatto che i vostri utenti troveranno questo metodo e avranno domande. La comparsa di questa autenticazione multipiattaforma (trasporto ibrido) si verificherà in particolare se gli utenti iniziano a eliminare le passkey localmente.

• Creare guide e tutorial completi che accompagnino gli utenti attraverso il processo di autenticazione passkey multipiattaforma (trasporto ibrido).
• Utilizzare tooltip in-app e sezioni di aiuto contestuale per guidare gli utenti durante la loro prima esperienza di autenticazione passkey multipiattaforma (trasporto ibrido).
• Fornire sezioni FAQ e di risoluzione dei problemi sul vostro sito web o all'interno dell'applicazione.

• Implementare sessioni a tempo per gli accessi con passkey tramite codice QR o Bluetooth per garantire che l'accesso sia solo temporaneo e sicuro.
• Assicurarsi che l'autenticazione passkey multipiattaforma (trasporto ibrido) non comprometta alcun protocollo di sicurezza esistente, mantenendo l'integrità dei dati dell'utente.
• Considerare le implicazioni sulla privacy e garantire che qualsiasi accesso temporaneo concesso tramite l'autenticazione passkey multipiattaforma (trasporto ibrido) sia registrato e monitorato secondo le migliori pratiche di sicurezza.

L'autenticazione passkey multipiattaforma tramite codice QR / Bluetooth (trasporto ibrido) offre un equilibrio tra sicurezza e UX. Tuttavia, è un processo completamente nuovo per la maggior parte degli utenti e potrebbe causare molte situazioni confuse, quindi è necessario riflettere attentamente se si desidera promuoverlo.

Speriamo di aver fatto un po' di luce sull'argomento dell'autenticazione passkey multipiattaforma (trasporto ibrido) tramite codice QR / Bluetooth, spiegando come configurare le cose e come si presenta il comportamento su diverse combinazioni di dispositivo / browser. Se avete domande, non esitate a contattarci tramite la nostra community di passkeys o iscrivetevi al nostro Substack sulle passkeys. Rendiamo Internet un posto più sicuro diffondendo le passkey.