Connexion WebAuthn

Découvrez la prise en charge de WebAuthn par Joomla, permettant aux utilisateurs de se connecter sans mot de passe à l'aide de dispositifs biométriques ou de clés de sécurité. La mise en œuvre de l'authentification sans mot de passe améliore la sécurité et le confort d'utilisation.

Connexion sans mot de passe WebAuthn

L'authentification web, ou WebAuthn en abrégé, permet à un utilisateur de se connecter de manière sécurisée à un site sans utiliser de mot de passe — bien qu'un identifiant soit toujours nécessaire. Elle utilise une cryptographie forte d'une manière extrêmement résistante aux problèmes les plus courants des mots de passe :

• quelqu'un l'a deviné (attaque par force brute)
• quelqu'un l'a intercepté (attaque de l'homme du milieu)
• quelqu'un vous a piégé pour le divulguer (attaque par hameçonnage)
• quelqu'un l'a cassé après avoir obtenu une copie des données de votre base de données (attaques par injection SQL)
• quelqu'un l'a volé.

WebAuthn n'est pas seulement très sécurisé ; il est également très convivial ! Vous n'avez plus besoin de mémoriser de longs mots de passe ni d'utiliser un gestionnaire de mots de passe. Tout ce dont vous avez besoin est un authentificateur, parfois aussi appelé clé d'accès.

Un authentificateur peut prendre de nombreuses formes, physiques ou virtuelles. Il peut s'agir d'une clé matérielle séparée se connectant à votre appareil via USB, Bluetooth ou NFC. Il peut s'agir de votre appareil lui-même, déverrouillant son authentificateur intégré avec un code PIN, un lecteur d'empreintes digitales, une reconnaissance faciale ou une vérification biométrique similaire.

Cette fonctionnalité fonctionne déjà sur les appareils Android et iOS/iPadOS et nous travaillons également à la rendre disponible sur Windows. Elle peut même utiliser votre téléphone — actuellement, cela est possible avec les téléphones Android, mais cette fonctionnalité arrive également sur les appareils iOS / iPadOS.

WebAuthn ne fonctionne que via HTTPS et uniquement lorsque votre site utilise un certificat valide et fiable à cet effet. Ne vous inquiétez pas, vous n'avez pas besoin de dépenser de l'argent supplémentaire ; des services gratuits comme Let's Encrypt sont généralement intégrés dans les panneaux de contrôle d'hébergement web et fonctionnent parfaitement avec WebAuthn.

WebAuthn utilise la cryptographie à clé publique, la même technologie éprouvée qui assure la sécurité de vos sites avec HTTPS, de vos informations bancaires, etc. La clé privée ne quitte jamais l'authentificateur. Votre site ne stocke qu'une clé publique. Même si vous subissez une violation de données, l'attaquant se retrouvera avec une clé publique pratiquement inutile ; il lui faudrait des milliers voire des millions d'années-CPU pour la casser, contre quelques minutes ou heures nécessaires pour casser le hachage d'un mot de passe fixe dont vous pouvez vous souvenir.

WebAuthn est l'avenir de l'authentification. Facile, sécurisée et sans tracas. Tout ce que les mots de passe fixes ne sont pas.

L'image suivante montre un dispositif matériel inséré dans le port USB d'un ordinateur portable. Il coûtait 15 £ en février 2022.

WebAuthn utilise un plugin système activé par défaut. Un bouton Authentification Web est présent, comme illustré sur l'écran de connexion de l'Administration :

Configuration de l'utilisateur

L'utilisateur doit d'abord s'enregistrer avec un identifiant et un mot de passe normaux. Après s'être connecté, accéder au formulaire de profil utilisateur. Pour un Administration :

• Sélectionner Menu Utilisateur → Modifier le compte → Connexion par authentification Web W3C (WebAuthn) pour afficher le formulaire, initialement sans authentificateur enregistré.
• Sélectionner Ajouter un nouvel authentificateur

La présentation exacte de l'étape suivante dépend de votre navigateur. En général, vous verrez une alerte, un message ou une fenêtre vous demandant de sélectionner un type d'authentificateur ou, si vous utilisez un authentificateur matériel connecté à votre appareil, vous rappelant d'appuyer sur le bouton de l'authentificateur matériel. Pour des raisons de sécurité et de praticité, un intervalle de temps relativement court est autorisé pour activer l'authentificateur : 60 secondes.

Une fois que vous déverrouillez votre authentificateur — en appuyant sur un bouton, en scannant votre empreinte digitale / votre visage, en saisissant un code PIN ou une combinaison de ces méthodes selon votre authentificateur — le message disparaît, l'authentificateur est enregistré et l'écran apparaît comme suit :

Il est très important de noter que vous ne pouvez enregistrer ou supprimer des authentificateurs que sur votre propre compte utilisateur. Pour des raisons de sécurité, même un Super Utilisateur n'est pas autorisé à enregistrer, modifier ou ajouter des authentificateurs sur d'autres comptes utilisateurs.

Authentificateurs

Vous pouvez utiliser n'importe quel authentificateur FIDO U2F ou FIDO2. FIDO U2F est une norme plus ancienne qui prend en charge une sélection plus limitée et moins sécurisée de méthodes cryptographiques. FIDO2 est la norme la plus récente qui prend en charge des méthodes cryptographiques bien plus sécurisées, notamment la cryptographie à courbe elliptique, une méthode cryptographique considérée comme résistante même à l'informatique quantique (si et quand elle deviendra une réalité pratique). De plus, les authentificateurs FIDO2 peuvent être configurés avec des protections supplémentaires telles qu'un code PIN ou un contrôle biométrique (par exemple, un scan d'empreinte digitale), ce qui signifie que même si vous perdez la possession physique de l'authentificateur, quiconque le trouve ne pourra pas se connecter à vos sites.

Si vous cherchez à acheter un authentificateur matériel, vous pouvez rechercher "FIDO2" sur votre place de marché préférée, comme Amazon. Il existe un large choix.

Vous pouvez également utiliser une clé FIDO logicielle telle que Krypton comme authentificateur.

De nombreux appareils disposent d'une authentification intégrée compatible FIDO2 :

• Joomla prend en charge l'authentification Windows Hello avec un code PIN, un lecteur d'empreintes digitales, une caméra de reconnaissance faciale ou une combinaison de clé matérielle et de code PIN.
• macOS dispose de TouchID sur tous les ordinateurs portables équipés de la puce T2 ou ceux basés sur Apple Silicon utilisant le capteur TouchID intégré, ainsi que sur tous les ordinateurs de bureau Apple Silicon utilisant le nouveau clavier Apple en aluminium doté d'un lecteur d'empreintes digitales.
• iOS / iPadOS dispose de TouchID sur tous les appareils équipés d'un lecteur d'empreintes digitales et de FaceID sur tous les appareils plus récents équipés d'une caméra à projection de points infrarouges FaceID.
• Certains appareils Android disposent d'un lecteur d'empreintes digitales ou d'une caméra de reconnaissance faciale. Ceux-ci peuvent également fonctionner comme authentificateurs FIDO2, sur Android 9 ou ultérieur en utilisant au moins Google Chrome.
• D'autres appareils peuvent également être disponibles. Par exemple, les téléphones Android utilisant caBLE

Navigateurs compatibles WebAuthn

Les navigateurs basés sur Chromium et Firefox prennent en charge WebAuthn depuis début 2019.

Safari et tous les navigateurs iOS/iPadOS (qui sont, en fait, Safari avec une apparence différente) prennent entièrement en charge WebAuthn depuis iOS/iPadOS 13, sorti fin 2019.

En pratique, si votre système d'exploitation et votre navigateur ont été publiés après mi-2020, vous ne devriez rencontrer aucun problème. Seuls quelques navigateurs très peu courants ne prennent toujours pas en charge WebAuthn.

Authentification

Pour vous connecter, vous devez saisir votre identifiant dans le champ Identifiant du formulaire de connexion. Vous n'avez pas besoin de saisir votre mot de passe, mais si votre navigateur le saisit automatiquement, laissez-le. Le mot de passe n'est PAS envoyé au serveur lorsque le formulaire est soumis via le bouton Authentification Web.

Il s'ensuit que vous pouvez vous connecter soit avec votre identifiant et votre mot de passe, soit avec votre identifiant et l'Authentification Web.

Comment désactiver le plugin

Si vous ne souhaitez pas autoriser WebAuthn, rendez-vous simplement dans la liste des plugins, trouvez System - WebAuthn Passwordless Login dans le groupe Système et désactivez-le. Il n'y a aucun paramètre à définir.

Exigences du serveur

Pour que WebAuthn fonctionne, les conditions préalables suivantes doivent être remplies :

• HTTPS avec un certificat valide et signé. La plupart des hébergeurs permettent d'utiliser gratuitement des certificats émis par Let's Encrypt. Ceux-ci fonctionnent parfaitement avec WebAuthn.
• L'extension PHP OpenSSL doit être installée et activée.
• L'extension PHP GMP ou l'extension PHP BCmath doit être installée et activée (l'une des deux suffit).
• La bibliothèque Sodium devrait idéalement être activée ; elle permet l'utilisation de la cryptographie à courbe elliptique sur les authentificateurs FIDO2 compatibles, qui, comme nous l'avons dit, est la méthode cryptographique la plus sûre.

Foire Aux Questions et Dépannage

Je ne vois pas le bouton de connexion « Authentification Web »

Vous n'accédez pas à votre site en HTTPS. WebAuthn n'est disponible que pour les sites HTTPS avec un certificat valide. Il s'agit d'une précaution de sécurité intégrée à la norme WebAuthn. Le plugin vérifie en réalité si le site est accédé via HTTPS en utilisant la classe Uri de Joomla. Dans de rares cas où le serveur ment sur le protocole, il se peut que vous ne voyiez pas le bouton même si votre site (prétend) être en HTTPS. Il en va de même si vous avez modifié votre fichier configuration.php et configuré le paramètre optionnel $live_site avec un préfixe de protocole http:// au lieu de https://.

Notez également que les modules et composants de connexion tiers mettant en œuvre leur propre formulaire de connexion peuvent ne pas encore afficher ces boutons. Nous avons ajouté une nouvelle infrastructure pour les prendre en charge, un peu comme ce que nous avons dû faire dans Joomla! 3.2 pour prendre en charge l'authentification à deux facteurs.

Je dois quand même saisir un identifiant. WebAuthn n'était-il pas censé se débarrasser des identifiants ?

Pas vraiment, non. La spécification actuelle de WebAuthn ne fournit pas de gestion d'identité. Les navigateurs web nous obligent à leur envoyer une liste de clés publiques WebAuthn acceptables pendant la phase de connexion. Cela signifie que nous avons besoin de votre identifiant pour les récupérer.

Cela dit, l'utilisation de WebAuthn met enfin en évidence le fait que les identifiants ne doivent pas être considérés comme des secrets. Ils sont considérés comme des informations publiques pouvant être librement transmises à un adversaire, tout comme les clés publiques stockées dans la base de données du site. Le seul secret est stocké dans l'authentificateur lui-même et ne quitte jamais l'authentificateur !

J'ai enregistré un authentificateur mais lorsque j'essaie de me connecter, on me dit que ce n'est pas le cas. Est-ce un bug ?

C'est un bug, mais pas dans le plugin WebAuthn lui-même.

Un ou plusieurs plugins de votre site génèrent des Notices, Avertissements ou Erreurs PHP, corrompant ainsi la réponse renvoyée par votre serveur. En conséquence, le JavaScript de la page ne peut pas analyser la réponse du serveur et ne sait pas si des authentificateurs sont enregistrés pour l'utilisateur.

Allez dans l'administration de votre site, Système, Configuration Générale, et réglez le Rapport d'Erreurs sur Aucun. Dans la plupart des cas de plugins natifs ou tiers mal configurés, cela suffit. Sinon, veuillez examiner la sortie de la requête à l'aide des outils de développement de votre navigateur pour voir ce qui corrompt la requête.

Il n'y a pas d'invite sur Safari pour utiliser mon authentificateur

Cela ne devrait plus se produire avec iOS 13, iPadOS 13 et macOS Catalina ou toute version ultérieure.

Il s'agit d'un bug de Safari dans les anciennes versions. Les anciennes versions de Safari n'incluaient la prise en charge de WebAuthn qu'en tant que fonctionnalité expérimentale et non totalement aboutie.

Je ne peux pas utiliser un capteur biométrique (TouchID, empreinte digitale, Windows Hello)

Certains anciens navigateurs basés sur Chromium (à l'exception de Google Chrome lui-même) ne prenaient pas entièrement en charge les authentificateurs intégrés. Ils plantaient ou se bloquaient lorsque vous essayiez d'en utiliser un. Ces problèmes ont été résolus dans ces navigateurs vers la mi-2020.

Si vous utilisez Windows, veuillez noter que votre appareil DOIT disposer d'une puce Trusted Platform Module (TPM) et qu'elle doit être activée dans le BIOS. Il ne suffit pas d'avoir un capteur biométrique compatible avec Windows Hello. Il s'agit d'une précaution de sécurité intégrée à la norme WebAuthn elle-même : les informations de l'authentificateur doivent être traitées à l'aide d'un matériel sécurisé et résistant à la falsification afin d'empêcher le détournement de la clé (par exemple, un logiciel malveillant s'exécutant sur l'ordinateur ne peut pas voler la clé utilisée pour l'authentification).

Enfin, gardez à l'esprit que la prise en charge de Windows Hello est toujours en cours de développement et sera publiée avec Joomla 4.2.

Si je peux utiliser un authentificateur logiciel, pourquoi devrais-je m'embêter avec un jeton matériel ?

La clé de voûte de WebAuthn est le secret absolu de la clé privée. Elle n'est connue que de l'authentificateur et il devrait être impossible de la communiquer au monde extérieur.

Dans le cas d'un authentificateur matériel, qu'il s'agisse d'un dispositif matériel distinct ou d'un module TPM / Secure Enclave intégré à votre appareil, cela est garanti par la nature même de ce matériel.

Un authentificateur logiciel génère une clé secrète et la stocke dans le système de fichiers. Cependant, il s'agit toujours d'une application logicielle classique qui s'exécute dans votre système d'exploitation habituel, que ce soit celui de votre téléphone ou de votre ordinateur. Par conséquent, il est vulnérable à plusieurs types d'attaques pouvant être utilisées pour voler subrepticement des informations (failles de sécurité dans le logiciel lui-même, logiciels malveillants exploitant des vulnérabilités de type Spectre dans les processeurs modernes, etc.).

Ainsi, un authentificateur logiciel est bien plus pratique et sécurisé qu'un mot de passe classique, mais un authentificateur matériel offre la meilleure sécurité. Choisissez votre authentificateur en fonction de votre budget et de vos besoins en matière de sécurité.

Étant donné que le prix d'une clé FIDO – compatible avec WebAuthn – est inférieur à 10 € sur Amazon, vous pouvez utiliser un authentificateur matériel dans la plupart des cas d'utilisation pratiques.

Pourquoi les informations d'identification sont-elles cryptées dans la base de données ? N'est-ce pas excessif ?

La seule chose stockée dans la base de données est la clé publique renvoyée par l'authentificateur lors de la cérémonie d'attestation (c'est le nom officiel de l'enregistrement d'un authentificateur selon la spécification WebAuthn). S'agissant d'une clé publique, elle n'a pas besoin d'être protégée contre la lecture. Même si un utilisateur non autorisé parvenait à lire cette information, il ne pourrait pas usurper l'identité de l'authentificateur, par exemple en le clonant.

Cependant, si un utilisateur malveillant disposait d'un accès en écriture uniquement à la table de base de données #__webauthn_credentials, sans accès en lecture au système de fichiers et sans accès en écriture à aucune autre table, il pourrait éventuellement ajouter son propre authentificateur, et ainsi usurper l'identité de l'utilisateur ciblé sur le système. Il s'agit d'une attaque très théorique car l'attaquant devrait également connaître l'identifiant utilisateur (user handle) de la personne visée, ce qui est difficile à déduire sans connaissance interne du site lui-même. De plus, il est extrêmement improbable d'obtenir un accès en écriture à cette seule table et non à l'ensemble de la base de données (auquel cas il pourrait créer un nouveau Super Utilisateur). Néanmoins, nous cryptons les informations d'identification afin de rendre impossible la réussite de cette attaque, même purement théorique.

Nous sommes pleinement conscients que si un utilisateur dispose d'un accès en lecture au système de fichiers du serveur, il a également accès à la clé de cryptage et aux informations de connexion à la base de données, le tout stocké dans configuration.php. Cependant, dans ce cas, vous êtes déjà piraté : l'attaquant peut lire configuration.php et sait donc comment se connecter à votre base de données. Dans ce cas, il peut faire ce qu'il veut sur votre site, y compris supprimer tous les Super Utilisateurs existants et créer son propre compte de Super Utilisateur. Il n'y a donc aucune raison d'essayer de remédier à cette situation ; vous seriez entièrement compromis (piraté). La seule chose qui pourrait vous sauver serait des sauvegardes régulières, testées et hors site.

J'ai configuré l'authentification à deux facteurs mais je suis connecté sans avoir à saisir ma clé secrète. N'est-ce pas un problème de sécurité ?

Non, c'est intentionnel et voulu dès la conception.

Lorsque nous avons ajouté l'authentification à deux facteurs (TFA) dans Joomla! 3.2, vous ne pouviez vous connecter à votre site qu'à l'aide d'un identifiant et d'un mot de passe. Les mots de passe peuvent être volés ou devinés. Par conséquent, la TFA était le seul moyen d'apporter un minimum de sécurité sur les cibles à haut risque et à forte valeur. C'était en 2013.

WebAuthn est une solution d'authentification entièrement différente qui ne présente aucun des problèmes des mots de passe fixes. Elle utilise une cryptographie forte et du matériel sécurisé pour rendre pratiquement impossible la compromission des clés cryptographiques d'authentification. Elle est également impossible à hameçonner, c'est-à-dire que vous ne pouvez pas être trompé en l'utilisant sur un site usurpant une identité, car l'identifiant WebAuthn est lié au nom de domaine exact pour lequel il a été émis (oui, si vous utilisez plusieurs domaines pour votre site ou si vous transférez votre site vers un autre domaine, vous devrez réenregistrer tous vos authentificateurs WebAuthn – vous avez bien compris !). En conséquence, l'authentification avec WebAuthn est incroyablement sécurisée et remplace les raisons qui rendaient la TFA nécessaire. Cela signifie que si vous vous authentifiez avec succès via WebAuthn, la clé secrète de la TFA n'a pas besoin d'être – et n'est donc pas – vérifiée du tout.

Dans un monde idéal, vous ne pourriez vous connecter à votre site qu'à l'aide de WebAuthn. C'est une fonctionnalité sur laquelle nous travaillons et que vous ne souhaiterez peut-être pas activer ; après tout, si le nom de votre domaine change ou si vous perdez l'accès à tous vos authentificateurs WebAuthn ou que vous les réinitialisez, vous seriez enfermé hors de votre site. C'est pourquoi vous devriez tout de même activer la TFA sur votre compte utilisateur, la connexion par mot de passe pouvant toujours servir de solution de secours pour se connecter à votre site et devant être protégée contre les attaques connues visant les mots de passe fixes.

La TFA n'est-elle pas suffisante ? Pourquoi avons-nous besoin de WebAuthn ?

La TFA seule est suffisante dans la plupart des cas, mais elle souffre de deux problèmes.

Premièrement, elle offre une expérience utilisateur plutôt maladroite. Vous devez saisir votre clé secrète, qui change constamment, avec votre identifiant et votre mot de passe. La plupart des gens utilisent le TOTP (le code PIN à six chiffres qui change toutes les 30 secondes), ce qui ralentit la connexion et tend à frustrer les utilisateurs. Utiliser une YubiKey est beaucoup plus rapide mais aussi plus coûteux et plus compliqué à mettre en place lorsque vous avez plus de deux ou trois utilisateurs sur le site. Une YubiKey a également une durée de vie estimée à environ 2 ans d'utilisation quotidienne lors de la génération de mots de passe à usage unique (One Time Passwords) (elle épuise la mémoire à écriture unique qu'elle utilise pour garder une trace des signatures qu'elle a émises).

Deuxièmement, si vous utilisez le TOTP, vous restez vulnérable à des problèmes de sécurité tels que les enregistreurs de frappe, l'hameçonnage et la possibilité que la clé secrète utilisée pour générer le TOTP soit volée. De plus, avec un million de possibilités et trente secondes pour les essayer, il est concevable qu'un attaquant ait de la chance, car Joomla ne verrouille pas votre compte ni n'applique de limitation de débit pour les tentatives de connexion échouées. Bien que ces protections puissent être mises en œuvre, leur mise en œuvre elle-même pourrait être détournée pour créer une situation de déni de service qui enferme un utilisateur légitime hors de son site pendant que l'attaquant s'affaire à l'infiltrer. C'est un cas où le remède serait pire que le mal.

WebAuthn améliore considérablement l'expérience utilisateur. Les principaux navigateurs ont adopté WebAuthn et offrent une expérience utilisateur convaincante, guidant les utilisateurs pour qu'ils utilisent les authentificateurs avec succès. Se connecter avec WebAuthn est plus pratique, même comparé à l'utilisation de la fonction de remplissage automatique d'un gestionnaire de mots de passe. Avec les versions récentes des systèmes d'exploitation mobiles, même cette expérience, autrefois légèrement déroutante, devient rapidement plus simple que les mots de passe et la TFA ne l'ont jamais été.

Là où WebAuthn excelle véritablement, c'est sur le plan de la sécurité. Grâce à l'utilisation de matériel sécurisé et à une validation stricte du nom de domaine du site, il est pratiquement immunisé contre les enregistreurs de frappe, le phishing et le détournement de clés. Il dispose même d'une protection intégrée contre le clonage de clés. Certes, vous pouvez toujours perdre votre matériel — mais les authentificateurs FIDO2, qu'il s'agisse de périphériques externes ou intégrés, peuvent être verrouillés par un code PIN ou des données biométriques. Dans l'ensemble, utiliser WebAuthn avec des authentificateurs FIDO2 est plus résistant au vol et à la perte que les clés de votre maison ou de votre voiture.

Notes pour les développeurs

Boutons de connexion supplémentaires

Le module du plugin et com_users utilisent maintenant l'évènement onUserLoginButtons, défini et appelé dans Joomla\CMS\Helper\AuthenticationHelper::getLoginButtons, pour récupérer les définitions de tous les boutons supplémentaires devant être placés après le bouton de connexion habituel.

Tous les développeurs implémentant un module de connexion ou, plus généralement, un formulaire de connexion devraient également utiliser la méthode publique statique Joomla\CMS\Helper\AuthenticationHelper::getLoginButtons pour récupérer ces définitions et afficher ces boutons afin de rendre leur logiciel pleinement compatible.

Les développeurs souhaitant implémenter des boutons personnalisés devraient regarder comment le plugin système WebAuthn met en œuvre cette fonctionnalité. De tels boutons peuvent être utilisés pour implémenter des services d'authentification unique (single-sign-on) tiers ou même pour se connecter à l'aide de services d'identité tiers tels que ceux proposés par les réseaux sociaux populaires (Facebook, Google, Twitter, GitHub, etc).

Ce changement n'a pas d'impact négatif sur la rétrocompatibilité. Les modules et formulaires de connexion tiers continueront de fonctionner normalement même s'ils n'implémentent pas la fonctionnalité de boutons de connexion supplémentaires, à l'exception notable des intégrations offertes par cette fonctionnalité, telle que l'Authentification Web elle-même. C'est-à-dire qu'ils ne cesseront pas de fonctionner (ce qui constituerait une rupture de rétrocompatibilité) mais ils ne seront pas complets en termes de fonctionnalités.

Autoriser com_ajax sur la page de connexion de l'Administration

La page de connexion de l'Administration place com_ajax sur liste blanche dans AdministratorApplication afin qu'il puisse être utilisé pour traiter les requêtes des utilisateurs invités.

Ce changement ne cause aucun problème de rétrocompatibilité tant que les développeurs utilisent de bonnes pratiques et ne supposent pas que le fait d'être appelé par com_ajax dans l'Administration prouve que l'utilisateur est connecté à l'Administration. Ce serait une mauvaise pratique de sécurité. La bonne pratique consiste à utiliser l'objet Utilisateur de Joomla! pour détecter s'il s'agit d'un utilisateur invité et, sinon, si l'utilisateur dispose du droit requis pour effectuer l'action demandée via com_ajax. C'est-à-dire que si ce changement a cassé votre code, c'est que votre code était déjà défectueux et devait de toute façon être revu.

Informations complémentaires

La documentation initiale de cette fonctionnalité se trouve dans la pull request PR #28094