Prise en charge de Webauthn

RFC Webauthn

Ce sujet vise à documenter les objectifs du projet Discourse concernant l’authentification FIDO2 / Webauthn.

Pourquoi ?

L’ajout de la prise en charge de Webauthn à Discourse augmentera la sécurité des comptes utilisateurs, permettant des comptes sans mot de passe facilement accessibles grâce aux fonctionnalités sécurisées de leurs appareils, comme un lecteur d’empreintes digitales sur smartphone.

Méthodes d’authentification

  • Webauthn comme authentificateur à deux facteurs (fonctionne comme une alternative à Google Authenticator)
  • Webauthn comme authentificateur à un facteur (fonctionne comme une alternative à la connexion sociale)
  • Webauthn comme authentificateur multifactoriel (connexion sans nom d’utilisateur)

Webauthn comme authentificateur à deux facteurs

Cela permettra à un utilisateur Discourse, qui possède déjà un compte actif, d’utiliser Webauthn comme 2FA, là où nous ne prenons actuellement en charge que le TOTP.

N’importe quelle méthode Webauthn peut fonctionner ici, qu’il s’agisse de biométrie de l’appareil (capteur d’empreintes digitales sous Android, Windows Hello sur ordinateur portable), d’une puce sécurisée de l’appareil (TPM, enclave sécurisée) ou d’une clé matérielle (comme une Yubikey).

Cela serait disponible pour tout utilisateur naviguant avec :

  • Microsoft Edge sur Windows, utilisant Windows Hello (avec reconnaissance faciale, lecteur d’empreintes digitales ou code PIN)
  • Chrome sur macOS, utilisant Touch ID
  • Téléphone Android
  • Ordinateur portable/ordinateur de bureau/téléphone + Clé physique (Yubikey, Google Titan)

Webauthn comme authentificateur à un facteur (comptes sans mot de passe)

Permet à un utilisateur de se connecter à son compte Discourse en utilisant l’authentification Webauthn comme alternative à un mot de passe. Si un authentificateur à un facteur est configuré, l’utilisateur sera invité à utiliser l’authentificateur au lieu d’un mot de passe.

Les mêmes méthodes d’authentification pour l’authentification à deux facteurs fonctionneront pour l’authentification à un facteur : biométrie, puce sécurisée ou clé matérielle.

Flux d’enregistrement


Aucun champ de mot de passe

Flux de connexion

Webauthn comme authentificateur multifactoriel (connexions sans nom d’utilisateur)

Exposera une méthode de connexion alternative qui ne demande que des entrées Webauthn. La clé de sécurité enregistrée transmettra également des informations sur l’ID utilisateur au serveur Discourse.

Cette méthode d’authentification nécessite actuellement une clé d’authentification moderne (par exemple une Yubikey 5) ainsi que Google Chrome 76+, car elle repose sur une fonctionnalité appelée « Clés résidentes ». Comme cela stocke des données sur l’authentificateur, il peut y avoir des limites ; par exemple, une Yubikey 5C ne peut stocker que jusqu’à 25 de ces clés.

Flux d’enregistrement

Ces flux sont une évolution de celui pour les connexions sans mot de passe, et non un flux de connexion séparé. Cela permet une mise en œuvre itérative.


Aucun champ de mot de passe, ajoute une case à cocher supplémentaire pour l’utilisation des clés résidentes

Flux de connexion


Si le nom d’utilisateur est laissé vide, nous essaierons de récupérer un user_id depuis l’authentificateur

Références

Démos

https://webauthndemo.appspot.com/

https://webauthn.io/dashboard

Ressources

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

22 « J'aime »

Merci pour cette RFC, elle est très complète ! J’ai cependant une réflexion concernant le flux d’utilisation de WebAuthn comme méthode d’authentification à deux facteurs (2FA) avec une connexion normale par nom d’utilisateur et mot de passe. Lorsque j’utilise la 2FA avec TOTP, je vois cette fenêtre modale lors de la connexion :

Si un utilisateur a à la fois des codes TOTP activés ET des authentificateurs WebAuthn, quel serait le flux ? L’utilisateur devrait-il décider dans cette fenêtre modale s’il souhaite utiliser WebAuthn ou son jeton 2FA ? Ou serait-ce trop contraignant ? Peut-être que Discourse pourrait par défaut demander WebAuthn si l’utilisateur l’a configuré et que le navigateur le prend en charge, puis basculer vers la 2FA en cas d’échec ?

Implémentations existantes

Twitter :



Github :


Compte Google :



6 « J'aime »

Oui, cela semble devenir la méthode standard pour mettre en œuvre WebAuthn, et j’aime beaucoup le flux de connexion. Je suis convaincu que nous irons également dans cette direction ici.

7 « J'aime »

Merci Jeff, cela a du sens. Quelques autres réflexions aujourd’hui après une investigation plus approfondie :

Authentification par premier facteur

  • Si un utilisateur crée un compte Discourse en utilisant WebAuthn comme méthode d’authentification par premier facteur, y aura-t-il un moyen ultérieur de passer à l’utilisation d’un mot de passe ? Et dans ce cas, l’authentification WebAuthn qu’ils ont configurée deviendrait-elle alors une méthode 2FA classique, jusqu’à ce qu’ils décident de la supprimer ?
  • Si WebAuthn a été utilisé comme méthode de premier facteur, apparaîtrait-il toujours dans l’interface utilisateur sous les préférences du second facteur, mais simplement non supprimable ?
  • Serait-il également juste de dire que l’utilisateur serait empêché de configurer des connexions via des réseaux sociaux de la même manière que s’il avait la 2FA activée ?
  • J’imagine que la section des préférences de l’utilisateur où l’e-mail de réinitialisation de mot de passe est envoyé changerait également, car ils n’auraient pas de mot de passe avec l’authentification par premier facteur :

6 « J'aime »

Côté rédaction, je n’aime pas utiliser le terme « WebAuthn » ; je pense qu’il est déroutant pour les utilisateurs finaux. Utilisez plutôt « Clé de sécurité » ou quelque chose de similaire.

Je souhaiterais vivement éviter de même penser à l’authentification « Premier facteur / sans mot de passe » ici ; pour moi, nous devons déployer cette fonctionnalité et vivre avec pendant 3 à 4 mois avant même d’envisager cela.

Surtout, puisque nous prenons déjà en charge la connexion par e-mail, vous pouvez techniquement oublier votre mot de passe.

Je suis d’accord pour que le flux soit le suivant : si vous le pouvez, que vous disposez des API et d’une clé WebAuthn, essayez d’abord WebAuthn, mais offrez à l’utilisateur une issue de secours. Gardez également à l’esprit que vous pouvez avoir plusieurs appareils WebAuthn ; je suivrais ce que fait Google à ce sujet pour gérer cela (un lien « Choisir une autre option » ou quelque chose de similaire).

Une chose à laquelle je pense sur le long terme, dans un élément séparé : nous pourrions utiliser l’« application Discourse » pour la double authentification, ce qui serait plutôt cool @pmusaraj. Cela pourrait rendre la double authentification beaucoup plus répandue.

14 « J'aime »

Oui, je suis d’accord. Le « webauthn » sur les maquettes n’est qu’un espace réservé.

Cela dit, « clé de sécurité » ne transmet pas le fait qu’un utilisateur peut utiliser l’empreinte digitale ou la caméra de son ordinateur portable ou de son téléphone.

Oui, les 3 méthodes présentées sont censées être mises en œuvre dans cet ordre, car la 1 est un peu plus simple mais pose les bases pour les 2 et 3.

6 « J'aime »

GitHub est du même avis :

8 « J'aime »

Concernant « WebAuthn en tant que premier facteur d’authentification », il existe une discussion dans la version 2 de la norme pour mentionner les implications en matière de confidentialité que cela peut entraîner : https://github.com/w3c/webauthn/pull/1250/

Concernant la dénomination des clés de sécurité, je suis d’accord pour les raisons exposées dans la PR de RubyGems.org.

J’ai également suggéré d’y ajouter un horodatage « dernière utilisation pour la connexion à » en plus du surnom de la clé de sécurité, afin de faciliter leur différenciation et de détecter d’éventuelles activités malveillantes.

8 « J'aime »

Au travail (dans un contexte de haute sécurité), nous avons également une alerte qui vous envoie un e-mail après qu’une clé de sécurité n’a pas été utilisée pendant 90 jours, vous invitant à l’utiliser ou à la supprimer de votre compte.

Je pense que mettre en place cela après 360 jours pourrait être une bonne idée ?

7 « J'aime »

Bonne idée. Un intervalle plus court serait gênant car nous utilisons des sessions « infinies » et je pense que la plupart des gens auront une clé quotidienne plus une de secours dans un tiroir. Sans compter les clés de sécurité natives sur plusieurs appareils.

6 « J'aime »

Je suis heureux d’annoncer que j’ai tout juste fusionné la PR pour cette fonctionnalité, nous allons donc pouvoir tester WebAuthn très, très bientôt ! :tada:

8 « J'aime »

Je viens d’ajouter mon empreinte digitale Android, ma Yubikey via NFC et ma Yubikey via USB-C, en utilisant Chrome Android et Firefox Desktop, et tout semble correct pour le moment.

Gros bug @Martin_Brennan @featheredtoast, impossible de se connecter en mode mobile :

Fonctionne parfaitement en mode bureau :

10 « J'aime »

Quelques retours aléatoires :slight_smile:

Cela ne semble pas correct :

Nous devrions suivre le compositeur ici pour la marge et la couleur de l’annulation.


Au lieu de « Password reset email », cela a l’air un peu décalé.

Peut-être plutôt ?

Continuer Annuler

Mot de passe oublié ? ← en gris clair


La saisie du mot de passe semble trop grande, elle devrait être un peu plus petite.


Je pense que cela devrait dire « Supprimer » ou « Effacer »


Si vous essayez d’ajouter une clé YubiKey que vous avez déjà ajoutée, un message d’erreur cryptique s’affiche.


En général :+1: :+1: :+1: :confetti_ball:

9 « J'aime »

Argh, je savais qu’il manquait une route dans la revue. Bonne détection :heart:

Je pense que cela fait un moment que c’est ainsi, mais oui, ce sont de bonnes modifications.

D’accord, bonne modification.

Peut-être pouvons-nous réutiliser le texte intégré de Chrome ici ? « Vous avez déjà enregistré cette clé de sécurité. Vous n’avez pas besoin de l’enregistrer à nouveau. » est une formulation claire et efficace.

9 « J'aime »

Merci @Falco et @sam pour vos retours. Je n’avais pas réalisé qu’il existait également une procédure différente pour la connexion mobile ! Je vais commencer à travailler sur ces corrections, y compris les modifications de l’étiquetage des mots de passe et des boutons, ce soir, et j’espère même ouvrir une nouvelle PR pour les résoudre !

7 « J'aime »

Je suis vraiment ravi que cela ait fonctionné sur votre Android également (même si la vue mobile ne fonctionne pas correctement) — je n’avais pas d’Android pour tester.

6 « J'aime »

Puis-je vous recommander le Xiaomi Mi 9 ?

3 « J'aime »

Je ne suis pas sûr d’être prêt à revenir à Android — j’adore trop mon iPhone 8 :sweat_smile:

5 « J'aime »

Voici la PR pour corriger ce qui précède :rocket:

6 « J'aime »

Qui a parlé de retour ? C’est une pensée du vieux monde ! Les gens modernes possèdent plusieurs appareils :wink:

8 « J'aime »