Suite à Support passwordless login with Passkeys et après quelques semaines de tests internes, nous sommes heureux d’annoncer que la prise en charge des passkeys est désormais disponible dans Discourse.
Que sont les passkeys ?
Les passkeys sont une alternative plus sûre et plus simple à l’utilisation des mots de passe pour l’authentification. La création et l’utilisation d’une passkey sont désormais largement prises en charge sur les plateformes et les navigateurs. Comparées aux mots de passe, les passkeys offrent une meilleure sécurité intégrée grâce à des identifiants solides générés par la plateforme et à une validation d’identité biométrique (comme TouchID, FaceID, un code PIN ou le mot de passe de l’appareil). Les passkeys sont également à l’abri des fuites côté serveur (la partie privée de la clé ne quitte jamais l’appareil) ou du phishing (chaque clé est liée à un seul site web/service).
Déploiement de la fonctionnalité
Si vous êtes un client hébergé, la prise en charge des passkeys sera déployée sur votre instance dans les prochains jours. Si vous souhaitez les activer dès maintenant, veuillez contacter @team ici sur meta ou par e-mail à team@discourse.org.
Si vous auto-hébergez Discourse, notez que la fonctionnalité sera activée par défaut dans le cœur de Discourse sous peu est maintenant activée par défaut dans le cœur depuis ce commit. Si vous souhaitez la désactiver, vous pouvez le faire via la console Rails :
launcher enter app
rails c
SiteSetting.enable_passkeys = false
Notez que les passkeys ne peuvent être utilisées que sur les instances Discourse avec les connexions locales activées. Si votre instance n’utilise pas de connexions locales, la fonctionnalité passkeys n’a aucun effet.
Une fois la fonctionnalité activée, les utilisateurs peuvent ajouter des passkeys à leur compte en se rendant dans l’onglet sécurité de leurs préférences utilisateur :
Une fois une passkey enregistrée, ils peuvent se connecter avec celle-ci via le menu déroulant de remplissage automatique sous le champ nom d’utilisateur (1) ou en cliquant sur le bouton “Se connecter avec une passkey” (2).
Une fois le déploiement initial de la fonctionnalité terminé, nous pourrions envisager les améliorations suivantes :
Permettre la configuration d’une passkey lors de la création du compte
Permettre l’utilisation des passkeys lors de la confirmation d’actions sensibles (actuellement pris en charge dans l’onglet Sécurité des Préférences utilisateur, mais pas dans certains écrans réservés aux administrateurs)
Permettre la suppression complète des mots de passe (par utilisateur ou par instance ?)
C’est un excellent ajout ! Cependant, les avantages en matière de sécurité peuvent être facilement contournés en se connectant avec un mot de passe. Je m’attendais à être toujours invité à utiliser une clé d’accès après avoir entré mon mot de passe, mais il se connecte simplement avec le mot de passe. Cela peut être évité en réenregistrant les clés de sécurité dans les paramètres 2FA séparés, mais ce n’est pas évident et c’est fastidieux.
Dans la plupart des implémentations actuelles, les clés d’accès ne sont pas encore déployées de cette manière. Elles sont traitées indépendamment de l’authentification à deux facteurs (2FA). Voir ce rapport sur l’approche de Youtube. Je pense que l’industrie s’adaptera lentement à cela.
Deux changements sont nécessaires pour que cela fonctionne comme vous l’attendez :
étape 1 : autoriser l’utilisation des clés d’accès comme 2FA (actuellement, comme vous l’avez noté, les clés de sécurité doivent être enregistrées indépendamment)
étape 2 : imposer la 2FA lors des connexions par mot de passe lorsqu’un utilisateur a ajouté une clé d’accès
L’étape 1 me semble logique et n’est pas perturbatrice. L’étape 2 semble également logique, mais elle est un peu perturbatrice : si l’utilisateur supprime la clé d’accès de son navigateur (ou n’en a pas sur un appareil donné), l’accès sera bloqué.
Je pense que Firefox travaille activement à ajouter la prise en charge des passkeys dans l’ensemble, mais ce n’est toujours pas acquis à 100 % si j’interprète correctement ce graphique.
Selon votre version et votre système d’exploitation, il se peut qu’elle ne soit pas encore disponible. Je viens de faire un test rapide sur macOS et iOS, et l’authentification par passkey était disponible et fonctionnelle pour moi ici sur meta.discourse.org.
Si la fonction de saisie semi-automatique du navigateur n’inclut pas la clé d’accès pour une raison quelconque, vous pouvez cliquer sur le bouton « Se connecter avec une clé d’accès ».
Vous pouvez écrire un message privé à @team ici ou envoyer un e-mail à team@discourse.org et nous pourrons désactiver cette fonctionnalité pour vous. Nous ne recommandons pas de le faire, de nombreux services sur le web adoptent les clés d’accès comme option d’authentification plus sûre.
Est-il prévu de pouvoir désactiver complètement le mot de passe à terme (de préférence par paramètre de compte, car je vois que forcer des sites entiers à le faire ne se terminerait pas bien) ? Parce qu’avoir à la fois une clé d’accès et un mot de passe actifs limite un peu l’utilité de la clé d’accès. Vous pouvez en quelque sorte atténuer cela en créant un mot de passe ridiculement complexe et en ne l’utilisant jamais, mais c’est juste contourner l’objectif des clés d’accès.
Oui, je pense que ce serait bien (et une sécurité améliorée pour le compte). Je l’ajoute maintenant dans la section « Améliorations futures possibles » de l’OP.
Si je comprends bien le mécanisme des clés d’accès, vous devez avoir installé un conteneur de confiance tel qu’un gestionnaire de mots de passe pour stocker les clés d’accès. Se débarrasser des mots de passe suppose que tous les utilisateurs ont installé un tel gestionnaire, alors comment les utilisateurs qui ne l’ont pas fait se connecteront-ils ?
De la même manière que les personnes qui n’utilisent pas la 2FA accèdent aux sites qui l’exigent : elles n’y accèdent pas.
Ce n’est pas une préoccupation réelle, car Chrome, Safari, Windows, iPhones, Android, Yubi, etc. sont tous des alternatives aux gestionnaires de mots de passe (que vous devriez déjà utiliser en 2024 de toute façon) et fonctionnent tous avec des passkeys.
Je ne suggérais pas non plus de forcer tous les utilisateurs à ne pas avoir de mot de passe (bien que cela me convienne), mais si VOUS, l’utilisateur de passkey, ne pouvez pas désactiver votre mot de passe, alors la passkey a beaucoup moins d’utilité et vous êtes toujours complètement vulnérable au phishing.
Si je choisissais les clés d’accès pour Discourse, je n’utiliserais plus mon mot de passe, alors comment pourrais-je être vulnérable au phishing ? Je comprends que le risque d’attaque malveillante ou par force brute sur la connexion par mot de passe subsistera, et votre suggestion de le désactiver par utilisateur est valable, mais pas par phishing ?
Des mises à jour concernant la création de compte uniquement avec des passkeys et sans mot de passe ? Il semble inutile de prendre en charge les passkeys si un mot de passe est toujours requis.
