Tuttavia, un piccolo dettaglio: su Safari/Mac, l’autenticazione web è una funzionalità riservata agli sviluppatori e disabilitata per impostazione predefinita. Una volta abilitata, funziona correttamente. Tuttavia, dovremmo probabilmente mostrare un messaggio o un avviso quando l’autenticazione web non è abilitata. Attualmente, su Safari con impostazioni predefinite, nulla nell’interfaccia utente indica che il processo di registrazione non funzionerà (la console mostra un errore):
Giusto, ma in questo caso si tratta di una parte normale del lavoro su Discourse, quindi copriremmo noi il costo. Scusa se non era chiaro, ma ora dovrebbe esserlo?
Congratulazioni per il supporto WebAuthn! È interessante vedere che avete sviluppato una soluzione propria invece di utilizzare il gem webauthn. Se ci sono feedback per noi, sarei felice di ascoltarli
Ho notato che nella vostra implementazione supporta solo l’algoritmo -7 (ES256), ma gli authenticator di piattaforma Windows Hello (supportati da hardware TPM 2.0) richiedono -257 (RS256) come indicato nella documentazione di Microsoft. Il TPM 2.0 è obbligatorio dal 28 luglio 2016 per i nuovi modelli desktop di Windows 10, quindi si tratta di una quantità di hardware non trascurabile.
Un suggerimento per il mockup del “Flusso di accesso”: WebAuthn dispone di un logo ufficiale che potrebbe essere utilizzato al posto di un’immagine generica dell’impronta digitale. Oltre all’impronta digitale, anche il riconoscimento facciale, lo schema di scorrimento o il PIN sono opzioni comuni di verifica dell’utente.
Grazie per il feedback, Rafe; dovremo quindi aggiungere l’algoritmo aggiuntivo. E grazie anche per il link al logo ufficiale! La mia idea, quando ho impostato un solo algoritmo, era semplicemente aggiungere il numero minimo di algoritmi supportati per far funzionare tutto nella versione V1, poiché non ero sicuro delle sfumature tra tutti gli algoritmi e ES256 era quello utilizzato in tutti gli esempi che ho potuto consultare.
Per quanto riguarda la ragione per cui all’epoca ho scelto di non utilizzare il gem, ci ho riflettuto a lungo e sapevo che prima o poi mi sarebbe stato chiesto di spiegare questa decisione. Ho sicuramente letto gran parte del codice del gem per comprendere meglio l’implementazione. Le ragioni principali sono state:
Non volevo aggiungere un’altra dipendenza a Discourse. Ogni dipendenza di gem aggiunge un sovraccarico aggiuntivo, indipendentemente da quanto eccellente possa essere il codice di quel gem.
Volevo avere una buona comprensione di come funziona questa componente di sicurezza critica di Discourse. Pensavo che avere il codice all’interno del nucleo di Discourse avrebbe reso le cose più chiare e più facili da estendere, senza dover affidarsi a una “scatola nera”, per così dire. (Non è una critica al gem stesso o alla sua complessità; mi rendo conto che chiunque potrebbe semplicemente consultare il codice lì, e ho trovato molto facile seguire ciò che stava accadendo).
Non volevo aggiungere più codice del minimo necessario per far funzionare WebAuthn; ad esempio, ho omesso l’attestazione dalla nostra implementazione iniziale. Non pensavo avesse molto senso aggiungere un intero arsenale di strumenti quando ci serviva solo una chiave inglese.
Detto questo, potrei aver sbagliato approccio, e se arriveremo alla versione V2, V3, ecc. del supporto WebAuthn con attestazioni, più algoritmi supportati e via dicendo, potrebbe diventare troppo laborioso per noi diventare “esperti di WebAuthn”, per così dire. A quel punto, penso che potremmo rivalutare l’uso del gem.
È un peccato che gli iPhone abbiano bisogno di un dispositivo di terze parti per questo. Spero che iOS++ lo abbia integrato con l’autenticazione del dispositivo e il chip di sicurezza. Come Windows, macOS e Android.
Sono così entusiasta di accedere a Discourse guardandolo!!
In realtà sono un po’ sorpreso che il supporto per l’autenticatore integrato non sia ancora disponibile… ma è comunque una notizia entusiasmante - continuerò a trattenere il fiato.
Ho notato una possibile incoerenza nell’interfaccia utente relativa all’indicazione dell’attivazione dell’autenticazione a due fattori (2FA) per alcuni utenti su un’istanza ospitata di Discourse:
L’elenco di tutti gli utenti ‘Staff’ non mostra il mio account come avente la 2FA abilitata:
La pagina di riepilogo dell’account suggerisce che la 2FA è attiva, dato il testo del pulsante ‘Gestisci autenticazione a due fattori’.
La sezione Autenticazione a due fattori indica che una chiave di sicurezza è abilitata e che il secondo fattore potrebbe essere disabilitato.
Altri utenti sulla stessa istanza che scelgono di utilizzare un autenticatore basato su token (senza chiave di sicurezza) mostrano l’icona del lucchetto nell’elenco ‘tutti gli utenti’.
Fate sapere se si tratta di un bug dell’interfaccia utente o se l’aggiunta di una chiave di sicurezza non è sufficiente per la 2FA su questa piattaforma.
Darò un’occhiata a questo, ma la mia ipotesi è che si tratti semplicemente di un bug dell’interfaccia utente nell’elenco degli utenti, se la sezione 2FA effettiva dell’interfaccia mostra tutto correttamente. Grazie per la segnalazione!
Apple si è unita alla FIDO Alliance (nota anche come Fast Identity Online), un’organizzazione che già include colossi come Google, Intel, Microsoft e Samsung.
