Aller au contenu

Utilisateur:Wikaeru/WebAuthn

Une page de Wikipédia, l'encyclopédie libre.

Modèle:Db-userreq

WebAuthn (Web Authentication) est un tentative du World Wide Web Consortium (W3C) [1] [2] avec la contribution de la FIDO Alliance [3] de standardiser 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 mot 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 mots de passe. Toutefois, pour plus de sécurité, le système qui demande l'authentification peut exiger ces informations, ce qui en fait un schéma d'authenfication 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 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 également ê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). Ceci est en général plus sécurisé, 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 de devenir rétro-compatible avec la norme U2F.

WebAuthn et CTAP font tous deux partie intégrante 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).

Prise en charge des applications et des appareils[modifier | modifier le code]

La proposition de recommandation "WebAuthn Level 1" a été publiée le 17 janvier 2019. [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 Firefox version 60, publié le 9 mai 2018. [5] La version actuelle de Microsoft Edge pour Windows Insider implémente une version de WebAuthn qui fonctionne à la fois avec Windows Hello et avec des clés de sécurité externes. [6]

Les clés de sécurité FIDO U2F existantes sont largement compatibles avec la norme WebAuthn, bien que WebAuthn ajoute la possibilité de référencer un identificateur unique "user handle" par compte, que les jetons d'authentification plus anciens ne peuvent pas stocker. [1] L'un des premiers authentificateur compatible avec WebAuthn était la YubiKey de deuxième génération de Yubico, annoncée le 10 avril 2018 [7]

Dropbox a annoncé la prise en charge des connexions WebAuthn (en tant que deuxième facteur d'authentification) le 8 mai 2018 [8]

API[modifier | modifier le code]

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.

Critique[modifier | modifier le code]

En août 2018, une équipe de chercheurs de Paragon Initiative Enterprises a réalisé un audit de sécurité du futur standard WebAuthn. Bien qu'elle n'ait pas détecté d'exploits, l'audit a révélé de graves faiblesses dans la manière dont la cryptographie sous-jacente au protocole est utilisée et prescrite par le standard. [9]

Les problèmes détectés avaient déjà impacté d'autres systèmes cryptographiques par le passé et doivent donc être corrigé 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 la 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 courbe, 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é 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é. 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.

Références[modifier | modifier le code]

  1. a b et c « Web Authentication: An API for accessing Public Key Credentials Level 1 », World Wide Web Consortium (W3C) (consulté le )
  2. « Web Authentication Working Group », W3C (consulté le )
  3. « FIDO2 Project », FIDO Alliance (consulté le )
  4. Brand, « Enabling Strong Authentication with WebAuthn », Google Developers, (consulté le )
  5. Shankland, « Firefox moves browsers into post-password future with WebAuthn tech », CNET, (consulté le )
  6. Sarkar, et. al., « Announcing Windows 10 Insider Preview Build 17682 », Microsoft, (consulté le )
  7. « Yubico Launches New Developer Program and Security Key for FIDO2 and WebAuthn W3C Specifications », (consulté le )
  8. Girardeau, « Introducing WebAuthn support for secure Dropbox sign in », Dropbox Tech Blog, Dropbox, (consulté le )
  9. « Security Concerns Surrounding WebAuthn: Don't Implement ECDAA (Yet) », Paragon Initiative Enterprises Blog, (consulté le )
  10. « FIDO ECDAA Algorithm », FIDO Alliance, (consulté le )

Liens externes[modifier | modifier le code]

[[Catégorie:Sécurité sur Internet]] [[Catégorie:Système d'authentification]] [[Catégorie:W3C]] [[Catégorie:Pages avec des traductions non relues]]