Supporto Webauthn

Contribuisci Funzionalità
1

RFC Webauthn

Questo argomento ha l’obiettivo di documentare gli obiettivi del progetto Discourse relativi all’autenticazione FIDO2 / Webauthn.

Perché?

Aggiungere il supporto Webauthn a Discourse aumenterà la sicurezza degli account utente, consentendo account senza password facilmente accessibili utilizzando le funzioni sicure dei dispositivi, come il lettore di impronte digitali di uno smartphone.

Metodi di autenticazione

  • Webauthn come autenticatore a due fattori (funziona come un’alternativa a Google Authenticator)
  • Webauthn come autenticatore a primo fattore (funziona come un’alternativa al login sociale)
  • Webauthn come autenticatore multifattore (accesso senza nome utente)

Webauthn come autenticatore a due fattori

Questo consentirà a un utente Discourse, che ha già un account attivo, di utilizzare Webauthn come 2FA, dove attualmente supportiamo solo TOTP.

Qualsiasi metodo Webauthn può funzionare qui, sia esso biometria del dispositivo (lettore di impronte digitali su Android, Windows Hello su laptop), un chip sicuro del dispositivo (TPM, enclave sicura) o una chiave hardware (come un Yubikey).

Questo sarà disponibile per ogni utente che naviga con:

  • Microsoft Edge su Windows, utilizzando Windows Hello (con riconoscimento facciale, lettore di impronte digitali o PIN)
  • Chrome su macOS, utilizzando Touch ID
  • Telefono Android
  • Laptop/Desktop/Telefono + Chiave fisica (Yubikey, Google Titan)

webauthn-2fa-mockup
webauthn-2fa-mockup1791×1268 131 KB

Webauthn come autenticatore a primo fattore (account senza password)

Consente a un utente di accedere al proprio account Discourse utilizzando l’autenticazione Webauthn come alternativa a una password. Se è configurato un autenticatore a primo fattore, all’utente verrà richiesto di utilizzare l’autenticatore al posto della password.

Gli stessi metodi di autenticazione per l’autenticazione a due fattori funzioneranno anche per l’autenticazione a primo fattore: biometria, chip sicuro o chiave hardware.

Flusso di registrazione

image
image507×583 27.2 KB

image
image474×492 16.5 KB

Nessun campo password

image
image425×152 7.65 KB

Flusso di accesso

860×793 42.8 KB

580×456 14.9 KB

421×150 7.82 KB

Webauthn come autenticatore multifattore (accessi senza nome utente)

Esporrà un metodo di accesso alternativo che richiede solo l’input Webauthn. La chiave di sicurezza registrata invierà inoltre le informazioni sull’ID utente al server Discourse.

Questo metodo di autenticazione richiede attualmente una chiave di autenticazione moderna (ad esempio Yubikey 5) più Google Chrome 76+, poiché si basa su una funzionalità chiamata “Resident Keys”. Poiché ciò archivia i dati sull’autenticatore, possono esserci limiti; ad esempio, Yubikey 5C può archiviare al massimo 25 di queste chiavi.

Flusso di registrazione

Questi flussi sono un’evoluzione rispetto a quello per gli accessi senza password, non un flusso di accesso separato. Ciò consente un’implementazione iterativa.

image
image507×583 27.2 KB

image
image478×536 20.7 KB

Nessun campo password, aggiunge una casella di controllo extra per l’uso delle Resident Keys

image
image425×152 7.65 KB

Flusso di accesso

860×793 42.8 KB

image
image367×305 10.5 KB

Se il nome utente viene lasciato vuoto, proveremo a recuperare un user_id dall’autenticatore

421×150 7.82 KB

Riferimenti

Demo

https://webauthndemo.appspot.com/

https://webauthn.io/dashboard

Risorse

https://medium.com/@herrjemand/introduction-to-webauthn-api-5fd1fb46c285

22 Mi Piace
Webauthn as first-factor
Discourse 2.4.0.beta6 Release Notes
Yubikey/U2F Key Support
Support passwordless login with Passkeys
Publishing DB backups without exposing users private information
2

Grazie per questa RFC, è molto completa! Ho però un pensiero riguardo al flusso per l’utilizzo di WebAuthn come metodo di autenticazione a due fattori (2FA) insieme a una normale login con nome utente e password. Quando ho il 2FA basato su TOTP, visualizzo questa finestra modale durante l’accesso:

image
image405×271 8.67 KB

Se un utente ha abilitati sia i codici TOTP che gli authenticator WebAuthn, come sarebbe il flusso? L’utente dovrebbe decidere in questa finestra modale se utilizzare WebAuthn o il proprio token 2FA? O forse sarebbe troppo oneroso? Forse Discourse potrebbe impostare come predefinito la richiesta di WebAuthn se l’utente lo ha configurato e il browser lo supporta, per poi passare al fallback sul 2FA?

Implementazioni esistenti

Twitter:

image
image601×287 6.73 KB

image
image613×329 11.1 KB

image
image613×313 13.8 KB

Github:

image
image707×133 7.31 KB

image
image733×313 12.9 KB

Account Google:

image
image677×809 48.9 KB

image
image685×813 21.6 KB

image
image683×733 23 KB

6 Mi Piace
3

Sì, sembra che questo stia diventando il modo standard per implementare WebAuthn, e mi piace molto il flusso di accesso. Sono convinto che anche noi ci orienteremo in questa direzione.

7 Mi Piace
4

Grazie Jeff, ha senso. Qualche altro pensiero oggi, dopo ulteriori indagini:

Autenticazione a Primo Fattore

  • Se un utente si registra a un account Discourse utilizzando WebAuthn come metodo di autenticazione a primo fattore, esiste un modo per passare in seguito all’uso di una password? E in tal caso, l’autenticazione WebAuthn configurata diventerebbe un normale metodo 2FA, fino a quando non decideranno di rimuoverla?
  • Se WebAuthn è stato utilizzato come metodo a primo fattore, apparirebbe comunque nell’interfaccia utente nelle preferenze per il secondo fattore, ma semplicemente non sarebbe rimovibile?
  • Sarebbe corretto dire che l’utente viene impedito di configurare accessi tramite social nello stesso modo in cui viene impedito se ha il 2FA abilitato?
  • Immagino che anche la sezione delle preferenze utente dove viene inviata l’email per il reset della password cambierebbe, dato che non avrebbero una password utilizzando il primo fattore:

image
image579×174 6.88 KB

6 Mi Piace
5

Dal punto di vista testuale, non mi piace usare il termine “Web Authn”; credo che possa confondere gli utenti finali. Meglio usare “Chiave di sicurezza” o qualcosa di simile.

Vorrei evitare anche solo di pensare a “autenticazione a primo fattore / senza password” in questo momento: per me, dobbiamo rilasciare questa funzionalità e conviverci per 3-4 mesi prima di prendere in considerazione altre opzioni.

Inoltre, dato che già supportiamo l’accesso tramite email, tecnicamente si può dimenticare la password.

Sono d’accordo sul fatto che il flusso dovrebbe essere: se puoi, hai le API e una chiave WebAuthn, prova prima WebAuthn, ma fornisci all’utente una via di fuga. Tieni anche presente che potresti avere più dispositivi WebAuthn; seguirei quanto fa Google per gestire questa situazione (ad esempio, un link “Scegli un’altra opzione” o qualcosa di simile).

Una cosa che penso a lungo termine, in un’attività separata, sarebbe poter utilizzare l’app “Discourse” per l’autenticazione a due fattori (2FA), il che sarebbe molto interessante @pmusaraj. Questo renderebbe l’uso del 2FA molto più diffuso.

14 Mi Piace
Support passwordless login with Passkeys
6

Sì, sono d’accordo. “webauthn” nei mockup è solo un segnaposto.

Detto questo, “chiave di sicurezza” non comunica il fatto che un utente può utilizzare l’impronta digitale o la fotocamera del proprio laptop o telefono.

Già, i tre metodi presentati dovrebbero essere implementati in quest’ordine, dato che il primo è un po’ più semplice ma getta le basi per il secondo e il terzo.

6 Mi Piace
7

Anche GitHub è della stessa opinione:

image
image367×488 15.3 KB

8 Mi Piace
8

Riguardo a “WebAuthn come primo fattore di autenticazione”, c’è una discussione nella versione 2 dello standard per menzionare le implicazioni per la privacy che questo può comportare: https://github.com/w3c/webauthn/pull/1250/

Riguardo alla denominazione delle chiavi di sicurezza, sono d’accordo per le ragioni esposte nella PR di RubyGems.org.

Ho anche suggerito lì di aggiungere un timestamp “ultimo utilizzo per il login” in aggiunta al nickname della chiave di sicurezza per aiutare a distinguerle e individuare eventuali attività malevole.

8 Mi Piace
9

Al lavoro (che è un contesto ad alta sicurezza) abbiamo anche un avviso che ti invia una email dopo 90 giorni di inattività della chiave di sicurezza, invitandoti a utilizzarla o rimuoverla dal tuo account.

Penso che implementare una funzionalità simile dopo 360 giorni potrebbe essere una buona idea?

7 Mi Piace
10

Ottima idea. Avere un intervallo più basso sarebbe fastidioso dato che usiamo sessioni “infinite” e penso che la maggior parte delle persone avrà una chiave giornaliera più una di riserva in un cassetto. Senza contare le chiavi di sicurezza native su più dispositivi.

6 Mi Piace
11

Sono lieto di annunciare che ho appena unito la PR per questa funzionalità, quindi potremo testare presto, molto presto, WebAuthn! :tada:

8 Mi Piace
12

Ho appena aggiunto l’impronta digitale Android, la Yubikey tramite NFC e la Yubikey tramite USB-C, utilizzando Chrome su Android e Firefox su Desktop e finora tutto sembra a posto.

Screenshot_20191002-000411
Screenshot_20191002-0004111080×2160 106 KB

Grande bug @Martin_Brennan @featheredtoast, non c’è modo di accedere nella visualizzazione mobile:

Screenshot_20191002-001000
Screenshot_20191002-0010001080×2160 212 KB

Funziona perfettamente nella visualizzazione Desktop:

Screenshot_20191002-001132
Screenshot_20191002-0011321080×2160 158 KB
Screenshot_20191002-001137
Screenshot_20191002-0011371080×2160 122 KB

10 Mi Piace
13

Alcuni feedback a caso :slight_smile:

Questo non sembra corretto:

image
image1670×372 17.1 KB

Dovremmo seguire il design del composer per quanto riguarda il margine e il colore di “Annulla”.

image
image599×120 3.13 KB

Invece di “Password reset email” sembra un po’ fuori posto.

Magari così?

Continua Annulla

Password dimenticata? ← in grigio chiaro

Il campo per l’inserimento della password sembra troppo grande, dovrebbe essere un po’ più piccolo.

image
image1138×899 51.9 KB

Credo che qui dovrebbe esserci scritto “Rimuovi” o “Elimina”

Se provi ad aggiungere una YubiKey già presente, appare un messaggio di errore criptico.

In generale :+1: :+1: :+1: :confetti_ball:

9 Mi Piace
14

Argh, sapevo che mi mancava una rotta in revisione. Ottimo rilevamento :heart:

Penso che sia così da un po’, ma sì, questi sono cambiamenti validi.

Sono d’accordo, ottimo cambiamento.

Forse possiamo riutilizzare qui il testo predefinito di Chrome? “Hai già registrato questa chiave di sicurezza. Non è necessario registrarla di nuovo.” è un testo chiaro ed efficace.

9 Mi Piace
15

Grazie @Falco e @sam per il vostro feedback. Non avevo capito che esistesse anche un percorso diverso per l’accesso da mobile! Inizierò a lavorare su queste correzioni, inclusi i cambiamenti alle etichette della password e ai pulsanti, stasera, e spero di aprire anche una nuova PR per risolvere il problema!

7 Mi Piace
16

Sono davvero contento che funzioni anche sul tuo Android (anche se la visualizzazione mobile non funziona correttamente) — non avevo un Android con cui testare.

6 Mi Piace
17

Posso consigliare lo Xiaomi Mi 9?

3 Mi Piace
18

Non sono sicuro di essere pronto a tornare su Android: amo troppo il mio iPhone 8 :sweat_smile:

5 Mi Piace
19

Ecco la PR per risolvere quanto sopra :rocket:

6 Mi Piace
20

Chi ha detto ‘torna’? È un pensiero del vecchio mondo! Le persone moderne possiedono più dispositivi :wink:

8 Mi Piace