Type a search term to find related articles by LIMS subject matter experts gathered from the most trusted and dynamic collaboration tools in the laboratory informatics industry.
WebAuthn (Web Authentication) est un standard du World Wide Web Consortium (W3C)[1],[2] avec la contribution de la FIDO Alliance[3] qui propose une interface d'authentification des utilisateurs aux applications Web à l'aide de clés asymétriques. Cette interface est une extension de l'API plus générale « Credential Management » qui définit comment les navigateurs Web ou autres agents utilisateur doivent interagir avec un gestionnaire de mots de passe.
WebAuthn peut être utilisé dans un contexte d'authentification simple, l'utilisateur n'étant pas obligé de fournir d'informations supplémentaires, comme un nom d'utilisateur ou un mot de passe. Toutefois, pour plus de sécurité, le système qui demande l'authentification peut exiger ces informations, ce qui en fait un processus d'authentification multifacteur. WebAuthn peut également être combiné à d'autres facteurs d'authentification, tels que des gestes ou une vérification biométrique, ce qui améliore la sécurité, tout en évitant aux utilisateurs de saisir des chaînes de caractères longues et complexes.
WebAuthn peut être implémenté de différentes façons, car les opérations cryptographiques sous-jacentes sont déléguées à un authentificateur, qui est un modèle fonctionnel abstrait. Cela permet d'implémenter entièrement WebAuthn dans un logiciel, ou d'utiliser le Trusted Execution Environment (TEE) d'un processeur ou encore un Trusted Platform Module (TPM). Les opérations cryptographiques sensibles peuvent aussi être déléguées à des jetons d'authentification externes auxquels on peut accéder via USB, Bluetooth ou par communication en champ proche (NFC). Cette pratique est en général considérée plus sécurisée, car les clés privées ne sont à aucun moment accessibles par les logiciels exécutés sur la machine. La communication avec les jetons d'authentification externes est conçue pour fonctionner avec le protocole CTAP (Client to Authenticator Protocol), ce qui permet à WebAuthn d'être rétrocompatible avec la norme U2F.
WebAuthn et CTAP font tous deux partie du projet FIDO2 qui vise à standardiser les processus d'authentification sécurisés et sans mot de passe et dépasse le cadre des navigateurs et du Web. Ces deux protocoles sont basés sur des travaux antérieurs effectués par la FIDO Alliance, en particulier sur les normes Universal Authentication Framework (UAF) et Universal 2nd Factor (U2F).
La proposition de recommandation « WebAuthn Level 1 » a été publiée le [1].
Google Chrome prend en charge WebAuthn depuis la version 67[4]. Mozilla Firefox, qui n'avait pas entièrement pris en charge le précédent standard FIDO U2F, a inclus et activé WebAuthn dans la version 60 de Firefox, publiée le [5]. En 2018, la version publiée de Microsoft Edge pour Windows Insider intégrait une version de WebAuthn qui fonctionnait à la fois avec Windows Hello et avec des clés de sécurité externes[6].
Les clés FIDO U2F existantes sont largement compatibles avec la norme WebAuthn, bien que WebAuthn ajoute la possibilité d'utiliser un identificateur unique (user handle) par compte, que les jetons d'authentification les plus anciens ne peuvent pas stocker[1]. L'un des premiers authentificateurs officiellement compatible avec WebAuthn était la YubiKey « Security Key » de Yubico, annoncée le [7].
Dropbox a annoncé la prise en charge des connexions WebAuthn (en tant que deuxième facteur d'authentification) le [8].
L'API WebAuthn étend les méthodes JavaScript navigator.credentials.create() et navigator.credentials.get() de l'API « Credential Management » afin qu'elles acceptent un paramètre publicKey.
La méthode create() est utilisée pour l'enregistrement d'authentificateurs en les associant à des comptes d'utilisateurs (par exemple au moment de la création du compte ou lors de l’ajout d’un nouveau dispositif de sécurité à un compte existant) alors que la méthode get() est utilisée pour l'authentification (par exemple lors de la connexion à un compte).
Pour vérifier si un navigateur implémente WebAuthn, les scripts doivent vérifier si l'interface window.PublicKeyCredential est définie.
En plus de PublicKeyCredential, la norme définit les interfaces AuthenticatorResponse, AuthenticatorAttestationResponse et AuthenticatorAssertionResponse, ainsi que divers dictionnaires et d'autres types de données.
À l'exception de la demande de création initiale, l'API n'autorise pas l'accès direct ni la manipulation de clés privées.
En , une équipe de chercheurs de Paragon Initiative Enterprises a réalisé un audit de sécurité du futur standard WebAuthn. Bien qu'aucun exploit n'ait été trouvé, l'audit a révélé de graves faiblesses dans la manière dont la cryptographie sous-jacente au protocole est utilisée et est prescrite par le standard[9].
Les problèmes détectés avaient déjà affecté d'autres systèmes cryptographiques par le passé et doivent donc être corrigés pour éviter des attaques similaires sur WebAuthn :
La FIDO Alliance a basé son standard sur un système de cryptographie asymétrique appelé ECDAA[10]. Il s'agit d'une version de Direct Anonymous Attestation (DAA) basée sur des courbes elliptiques. Dans le cas de WebAuthn, elle est censée être utilisée pour vérifier l'intégrité des authentificateurs, tout en préservant la confidentialité des utilisateurs, car elle ne permet pas une corrélation globale des identificateurs. Cependant, ECDAA ne tient pas compte de certaines des leçons tirées des dernières décennies de recherche dans le domaine de la cryptographie sur les courbes elliptiques, car la courbe choisie présente certains déficits de sécurité inhérents à ce type de courbes, ce qui réduit considérablement les garanties de sécurité. De plus, la norme ECDAA implique des signatures aléatoires, non déterministes, ce qui a déjà posé un problème par le passé.
Les auditeurs de Paragon Initiative Enterprises ont également critiqué la façon dont la norme a été élaborée, car la proposition n'a pas été rendue publique à l'avance et la communauté des cryptographes n'a pas été sollicitée. Par conséquent, la norme n'a pas été soumise à des recherches cryptographiques poussées dans le monde universitaire.
Malgré ces problèmes, les chercheurs de Paragon Initiative Enterprises encouragent les utilisateurs à continuer d'utiliser WebAuthn, mais ont formulé des recommandations qu'ils espèrent voir mises en œuvre avant la finalisation de la norme. Corriger ces erreurs le plus tôt possible éviterait à l’industrie les difficultés liées à l’obsolescence prématurée de la norme et à la nécessité de compatibilité descendante.
LIMS forum content by LIMS forum members is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. Based on a work at www.limsforum.com.
