WebAuthn dans la vraie vie

En septembre 2019, l'équipe Mail.ru Mail a pris en charge la technologie WebAuthn. Nous sommes devenus le premier service de messagerie au monde à avoir mis en place la possibilité de se connecter à votre compte à l'aide de clés électroniques au lieu de mots de passe. Maintenant, cette opportunité est disponible pour tous nos utilisateurs, vous pouvez lier la clé électronique à votre compte dans les paramètres et ensuite l'utiliser librement pour entrer.



Nous avons déjà écrit des nouvelles de cet événement ici, sur Habré. Dans cet article, je veux parler davantage des raisons de l'implémentation de WebAuthn dans nos services et des aspects techniques de l'utilisation de cette technologie.

Qu'est-ce que WebAuthn et pourquoi est-il nécessaire


Dans le monde moderne, la plupart des services Internet utilisent des mots de passe pour authentifier les utilisateurs. L'avantage des mots de passe est leur simplicité: pour accéder à la ressource nécessaire il suffit de connaître le mot de passe et de le saisir correctement.

Cependant, les inconvénients des mots de passe l'emportent souvent sur leurs avantages:

  • si le mot de passe est simple - vous pouvez le récupérer;
  • si le même mot de passe est utilisé dans plusieurs services, puis en cassant l'un d'eux, l'attaquant a accès à tous les autres;
  • les mots de passe sont vulnérables aux attaques de phishing;
  • des mots de passe forts et uniques sont difficiles à retenir, donc l'utilisateur est obligé d'écrire le mot de passe sur l'autocollant et de le coller sur le moniteur, d'où il peut être facilement espionné, volé ou perdu.

Pour se débarrasser des lacunes des mots de passe et rendre le processus d'authentification plus sûr, différentes façons de remplacer les mots de passe apparaissent - il s'agit de l'utilisation de codes à usage unique qui sont envoyés à l'utilisateur via SMS ou via des notifications PUSH, ou l'utilisation d'applications spéciales de générateur de code TOTP avec lesquelles l'utilisateur peut se connecter. sans saisir votre mot de passe.

Des entreprises telles que Microsoft , Yahoo , Amazon envisagent d'utiliser des méthodes d'authentification sans mot de passe et abandonnent complètement l'utilisation de mots de passe dans leurs services. Mail.ru mail ne fait pas exception, nous avons longtemps pris en charge la connexion à l'aide de codes à usage unique, ce qui permet aux utilisateurs de ne pas se souvenir de mots de passe complexes et forts et d'accéder rapidement à leur compte.

Une autre alternative aux mots de passe est l'authentification à l'aide de clés électroniques (clés de sécurité, autre nom - authentificateurs électroniques). Le principe de son fonctionnement repose sur l'utilisation de la cryptographie asymétrique et est décrit dans la famille de protocoles FIDO2, développée par l'alliance FIDO (Fast IDentity Online).

En mars 2019, le W3C a publié la première version de la norme., qui décrit une API JS basée sur un navigateur qui vous permet d'interagir avec des clés électroniques. La norme a reçu l'état de recommandation et le nom Authentification Web: API pour l'accès aux informations d'identification à l'aide d'une clé publique: niveau un (Authentification Web: API pour accéder aux informations d'identification de clé publique niveau 1) - abrégé en WebAuthn.

Fonctionnement de WebAuthn


Les acteurs clés suivants du processus d'authentification à l'aide de WebAuthn sont identifiés:

  • Client (WebAuthn Client) - un navigateur qui prend en charge l'API WebAuthn;
  • Application Web - une application exécutée sur le client à l'aide de l'API WebAuthn pour interagir avec les informations d'identification;
  • informations d'identification (informations d'identification de clé publique) - une paire de clés cryptographiques publiques et privées associées à un compte d'utilisateur;
  • Authenticator - un appareil ou un programme - crée les informations d'identification de l'utilisateur et signe les demandes de la partie utilisatrice avec ces informations d'identification (un autre nom est une clé électronique);
  • la partie de confiance (WebAuthn Relying Party) - le serveur web - stocke la clé publique associée au compte utilisateur, vérifie la validité de la signature de leurs demandes avec la clé privée stockée dans l'authentificateur.

L'API WebAuthn vous permet d'effectuer seulement deux opérations. Il vous permet de créer de nouvelles informations d'identification et de signer des demandes à partir du serveur avec des informations d'identification déjà créées.

Création d'informations d'identification ( MakeCredential )



Schéma de la scène avec la création des pouvoirs, extrait de w3.org .

A ce stade, la clé électronique est enregistrée dans le compte utilisateur. À l'intérieur de l'authentificateur, une nouvelle paire de clés publiques et privées est générée, et la clé publique est envoyée et stockée dans le compte d'utilisateur sur le serveur.

const credential = await navigator.credentials.create({
    publicKey: publicKeyMakeCredentialOptions
});

Signature d'une demande avec des informations d'identification déjà créées ( GetAssertion )



Schéma de la scène avec vérification des pouvoirs, extrait de w3.org .

A cette étape, il est vérifié si l'utilisateur dispose d'un authentifiant dont la clé publique est stockée dans le compte utilisateur. Un jeton aléatoire est signé avec la clé privée à l'intérieur de l'authentificateur et envoyé au serveur, où le serveur vérifie que la signature est correcte. Par conséquent, si la signature est correcte, nous concluons que l'utilisateur a vraiment cet authentificateur.

const assertion = await navigator.credentials.get({
    publicKey: publicKeyGetAssertionOptions
});

Vous pouvez voir une démonstration du processus de saisie de Mail.ru Mail à l'aide de WebAuthn dans cette vidéo .

Vous pouvez en savoir plus sur l'API WebAuthn elle-même dans la spécification WebAuthn et, par exemple, dans cet article Medium .

Ainsi, le travail de WebAuthn est basé sur l'utilisation de clés électroniques. Qu'Est-ce que c'est?

Clés électroniques


Les clés électroniques (je les appellerai parfois aussi «clés WebAuthn», clé de sécurité de sécurité) sont des dispositifs ou des programmes qui mettent en œuvre des protocoles d'interaction FIDO2.

Dans la spécification WebAuthn et au niveau des ménages, toutes les clés électroniques sont classées dans l'une des deux catégories:

  • clés indépendantes de la plateforme (authentificateurs itinérants);
  • Authentificateurs de plate-forme

Les clés indépendantes de la plate-forme sont des appareils physiques externes, tels que Yubikey de Yubico ou Titan Security Key de Google. En règle générale, ces authentificateurs sont connectés à l'ordinateur ou au smartphone de l'utilisateur via USB, NFC ou BLE. La communication avec ces appareils se fait à l'aide du protocole CTAP spécial (Client to Authenticator Protocol).

Pour commencer à travailler avec des clés électroniques physiques, l'utilisateur doit le lier une fois à son compte. Après cela, l'utilisateur a la possibilité d'utiliser cette clé électronique pour entrer sur n'importe quel autre appareil et dans n'importe quel navigateur.


Exemples de différentes clés indépendantes de la plateforme, tirées de theverge.com .

Si le mécanisme de fonctionnement du premier type de touches est plus ou moins clair, alors je veux m'attarder plus en détail sur la deuxième catégorie.

Dans le second cas, les clés cryptographiques publiques et privées sont générées et stockées non pas à l'intérieur d'un appareil physique externe, mais avec un module logiciel à l'intérieur d'un ordinateur ou d'un smartphone. Ce module logiciel peut être implémenté au niveau de l'application spécifique ou au niveau du système d'exploitation. Par exemple, dans une puce sécurisée à l'intérieur d'un ordinateur, à laquelle votre système d'exploitation ne donnera accès que si vous êtes connecté et avez prouvé que vous êtes vraiment vous.

Dans la plupart des implémentations modernes dans différents navigateurs, le système d'exploitation nécessite que l'utilisateur se confirme soit avec une empreinte digitale, soit en entrant le mot de passe du compte utilisateur. Il est important de préciser que bien que l'utilisateur doive mettre son doigt sur le lecteur d'empreintes digitales pour utiliser ces clés, l'empreinte digitale elle-même n'est stockée nulle part et n'est transmise nulle part. C'est juste la façon dont le système d'exploitation ou le navigateur valide l'utilisateur.


Utilisation d'authentificateurs spécifiques à la plate-forme.

Seules les informations de clé publique codées ou un jeton aléatoire signé sont renvoyés au service Web à partir de l'API WebAuthn, qui est ensuite stocké et vérifié côté serveur.

Par conséquent, dans le cas de l'authentificateur intégré, il ne sera possible de l'utiliser que sur le navigateur et l'appareil où il a été attaché au compte. En d'autres termes, les clés dépendantes de la plateforme devront être enregistrées séparément sur chaque appareil / navigateur dans lequel vous avez l'intention de vous connecter à votre compte.

À l'avenir, d'autres moyens devraient apparaître, qui permettront à l'utilisateur d'activer l'utilisation d'authentificateurs spécifiques à la plate-forme, par exemple en utilisant une numérisation faciale ou en entrant un code PIN à partir de l'appareil.

Lors de la création d'informations d'identification ou du calcul de la signature, vous pouvez spécifier le type préféré d'authentificateur dans un paramètre spécial qui prend deux valeurs - cross-platformet platform. Dans ce cas, l'utilisateur sera invité à n'utiliser qu'un seul des types de clés électroniques.

const credential = await navigator.credentials.create({
    publicKey: {
        authenticatorSelection: {
            authenticatorAttachment: 'cross-platform',
        },
        ...,
    },
});

Avantages sociaux chez WebAuthn


Quels sont les avantages de la technologie WebAuthn pour les utilisateurs et les développeurs?

  • L'utilisateur n'a pas besoin de se souvenir et de saisir des mots de passe, et le serveur ne stocke pas les mots de passe des utilisateurs, respectivement, tous les défauts que les mots de passe avaient disparus. Voler un authentifiant physique à un utilisateur est beaucoup plus difficile que d'intercepter un mot de passe transmis électroniquement via une connexion non sécurisée, et une fuite de clés publiques sur le site n'ouvrira pas la clé privée cachée dans l'appareil.
  • origin , . origin . , (thesslstore.com, yubico.com) .
  • WebAuthn - . - web- , .
  • WebAuthn lui-même en tant qu'API fournit aux développeurs une abstraction sur la mise en œuvre des authentificateurs et vous permet d'écrire du code une fois, qui fonctionnera ensuite avec tous les types et types de clés électroniques. Ainsi, WebAuthn est une solution évolutive pour l'authentification des utilisateurs.

Encore plus sur pourquoi WebAuthn est plus sûr qu'un mot de passe - WebAuthn pour les développeurs: 5 étapes pour une meilleure authentification , Premiers pas avec les clés de sécurité .

Prise en charge de WebAuthn


Que l'authentification par clé électronique fonctionne ou non sur votre appareil dépend de plusieurs facteurs différents. En partant du fait que votre navigateur prend en charge l'API WebAuthn et en terminant par les connecteurs présents sur votre ordinateur et les méthodes de communication prises en charge par votre authentificateur. Les performances de WebAuthn dépendent également fortement de l'appareil et du système d'exploitation que vous utilisez.

Au moment de la rédaction du présent rapport, selon caniuse.com, l' API WebAuthn est prise en charge par 80,5% des utilisateurs. Selon les statistiques sur les utilisateurs de Mail.ru, ce chiffre a le même ordre - 79,8%. Cependant, pour utiliser WebAuthn dans tous ces navigateurs, vous aurez certainement besoin d'une clé électronique externe.

Tous les navigateurs qui prennent en charge l'API WebAuthn ne peuvent pas fonctionner avec des clés dépendantes de la plate-forme (pour plus de commodité, je ferai référence à ces clés comme «empreintes digitales» plus tard). De plus, pour travailler avec de telles clés, il ne suffit pas d'installer un navigateur capable de les utiliser. Il est également nécessaire que votre appareil et votre système d'exploitation disposent d'un module / capteur approprié et puissent interagir avec eux. De tous les utilisateurs de Mail.ru, seulement 9,0% ont la possibilité d'ajouter des clés spécifiques à la plate-forme.

Je vais vous parler brièvement de la prise en charge de WebAuthn par différents systèmes d'exploitation et navigateurs.

les fenêtres


La prise en charge de WebAuthn sur Windows est très bonne. Le sous-système d'authentification Windows Hello peut fonctionner avec des clés électroniques. Par conséquent, toutes les dernières versions du navigateur pour ce système d'exploitation - Microsoft Edge, Google Chrome, Opera et Mozilla Firefox - prennent en charge le travail avec les clés étrangères et les empreintes digitales. API Internet Explorer WebAuthn ne prend pas en charge.


Linux


Les authentificateurs externes sont généralement pris en charge par toutes les distributions Linux modernes, ainsi que par les navigateurs tels que Google Chrome, Chromium et Mozilla Firefox. Cependant, sur certains systèmes, des paramètres supplémentaires peuvent être nécessaires pour travailler avec des clés étrangères .

Android


Le support de WebAuthn sur Android est également bon. Google Chrome, Opera et Mozilla Firefox - prennent en charge le travail avec les clés étrangères et les empreintes digitales. Mais Microsoft Edge pour Android ne prend pas du tout en charge l'API WebAuthn. Il y a aussi un bogue dans Firefox - spécifier le type préféré d'authentificateur en utilisant l'option ne fonctionne pas pour lui authenticatorAttachment.


iOS


Parmi tous les navigateurs pour le système d'exploitation iOS, WebAuthn ne prend en charge que la version 13.3 de Safari mobile. De plus, il ne peut travailler qu'avec des clés électroniques externes. Les autres navigateurs pour iOS ne prennent pas encore en charge WebAuthn.

macOS


Microsoft Edge, Google Chrome, Opera et Mozilla Firefox prennent en charge l'utilisation de clés étrangères sur macOS. Google Chrome prend également en charge les empreintes digitales, vous permettant d'utiliser WebAuthn avec Touch ID.


Si dans Edge, Opera et Chrome, l'interface pour interagir avec WebAuthn est la même, Firefox se distingue ici. Au lieu d'une jolie fenêtre contextuelle dans Firefox, lors de l'utilisation de WebAuthn, une petite notification apparaît dans le coin de l'écran. Si vous cliquez accidentellement sur une page, celle-ci s'effondre simplement, laissant l'utilisateur perdu ce qui se passe maintenant.



Cependant, Safari n'a pas encore pris en charge WebAuthn. La prise en charge de WebAuthn a été annoncée dans Safari 13, qui sera disponible sur macOS 10.15 Catalina. Cependant, au moment de la rédaction, mes vérifications ont montré que l'API WebAuthn dans Safari, bien que présente, est extrêmement instable et ne fonctionne pas avec tous les authentificateurs. Comme sa version mobile, Safari ne fonctionne pas avec les clés électroniques intégrées. De plus, il ne prend en charge aucune des clés électroniques étrangères.

Nous avons donc réalisé qu'en plus des problèmes de support, WebAuthn présente des différences encore plus importantes dans l'interface utilisateur. Ces différences conduisent au fait que vous devez expliquer plus en détail à l'utilisateur ce qui est exigé de lui pour pouvoir utiliser l'entrée via des clés électroniques. De plus, à chaque nouvelle version du navigateur, ces fenêtres contextuelles peuvent changer et le processus d'utilisation de WebAuthn aujourd'hui peut être très différent de ce qu'il était hier.

Il est clair pourquoi cela se produit. La technologie WebAuthn est encore assez jeune et les développeurs de navigateurs expérimentent toujours différents types d'implémentation. On ne peut qu'espérer qu'avec le temps la prise en charge de WebAuthn dans les navigateurs se stabilisera et que nous pourrons l'utiliser sans restrictions.

Enregistrement d'authentificateur


Si nous donnons à l'utilisateur la possibilité d'enregistrer différentes clés électroniques dans son compte, il devrait avoir la possibilité de consulter leur liste et d'en supprimer les obsolètes ou inutiles. Cela peut être utile, par exemple, en cas de compromission d'une des clés.

L'API WebAuthn est conçue de sorte que lors de la création et de l'utilisation des informations d'identification, le client ne dispose d'aucune information sur le type, le type et le nom des authentificateurs utilisés. En conséquence, nous ne disposons d'aucune donnée permettant de distinguer une clé d'une autre. Toutes les clés de la liste seront présentées de manière égale sans distinction de caractéristiques. Question: que faire?


Vous pouvez obtenir des informations sur l'authentificateur utilisé si vous demandez les soi-disant informations d'identification lors de la création des informations d'identification. certification. La certification est un moyen pour un authentificateur de prouver son authenticité à un serveur. Dans certains cas, des informations sur le fabricant clé peuvent être obtenues auprès de la certification. Mais dans le cas général, les données utilisées ne sont toujours pas suffisantes pour distinguer clairement une clé électronique associée à un compte d'une autre.

const credential = await navigator.credentials.create({
    publicKey: {
        attestation: 'direct',
         ...,
    },
});

Par conséquent, après avoir connecté la clé au compte dans Mail, nous donnons à l'utilisateur la possibilité d'attribuer un nom à l'enregistrement nouvellement créé. Et déjà plus loin, l'utilisateur peut distinguer une clé d'une autre par ce nom.

Le fait que les informations disponibles pour le client et le serveur ne contiennent aucune donnée sur le type d'authentificateur conduit à une autre caractéristique désagréable de WebAuthn.

Imaginez un utilisateur qui n'a ajouté qu'une seule empreinte digitale à son compte, par exemple, dans son smartphone. Lorsque nous voulons nous connecter à l'aide de l'API WebAuthn, nous passons un appel de fonctionnavigator.credentials.getliste de toutes les clés associées à un compte. Mais le navigateur ne peut pas déterminer à partir de cette liste quels authentificateurs sont présents sur l'appareil et lesquels ne le sont pas. Par conséquent, il est obligé de toujours proposer à l'utilisateur d'utiliser WebAuthn.

Par conséquent, même lorsqu'il essaie de se connecter à un compte sur un ordinateur qui ne prend pas en charge l'authentification via les empreintes digitales, l'utilisateur sera toujours proposé d'utiliser WebAuthn.

Pour implémenter le comportement correct dans de telles situations, vous devez affiner la norme WebAuthn elle-même. Par exemple, pour coder des informations indiquant si une clé multiplateforme ou une empreinte digitale a été utilisée lors de leur création et ne pas proposer à l'utilisateur WebAuthn dans les cas où il est connu à l'avance qu'il ne pourra pas l'utiliser.

Il existe des moyens de contourner ce comportement dans certaines situations. Par exemple, autorisez l'utilisateur à enregistrer les empreintes digitales et les clés physiques uniquement individuellement. Et lorsque vous utilisez des clés, filtrez les empreintes digitales sur les appareils qui ne les prennent évidemment pas en charge. Mais cette méthode ne résout pas complètement le problème. Et il n'y a aucun moyen fiable de résoudre ce problème.

Nos utilisateurs n'ont pas encore reçu de plaintes concernant ce comportement, nous étudions actuellement cette fonctionnalité et décidons de ce que nous allons faire à l'avenir.

WebAuthn travaille sur différents sous-domaines


Comme je l'ai dit plus tôt, WebAuthn offre une protection prête à l'emploi contre le phishing. Lors de l'enregistrement des clés électroniques, les informations originsur lesquelles cette clé a été enregistrée sont stockées . WebAuthn n'autorise pas l'utilisation de cette clé électronique sur les ressources, avec une autre origin.

Les grands services Web tels que Mail.ru utilisent souvent plusieurs domaines différents pour leur travail. Par exemple, nous avons un domaine e.mail.rupour Mail et cloud.mail.rupour le Cloud. Et sur chacun d'eux, nous avons une forme d'autorisation commune. Dans ce cas, les paramètres standard de WebAuthn ne sont pas suffisants. Afin que nous puissions utiliser des originclés enregistrées sur l'autre sur l'une origin, il est nécessaire que ces deux domaines aient un suffixe commun (un sous-domaine commun de plus que le premier niveau).

Par exemple dans les domainese.mail.ruet le cloud.mail.rusuffixe commun est mail.ru.

Dans ce cas, lors de l'enregistrement et de l'utilisation de clés électroniques, nous pouvons spécifier un paramètre rpIdégal dans les options de demande mail.ru, puis nous pouvons utiliser la même clé sur la sous-clé elle-même https://mail.ruet sur l'un de ses sous-domaines.

const credential = await navigator.credentials.create({
    publicKey: {
        rp: {
            name: 'Mail.ru Group',
            id: 'mail.ru',
        },
        ...,
    },
});

WebAuthn fonctionne dans iframe


Pour des raisons de sécurité, les appels aux méthodes WebAuthn sont interdits à l'intérieur des iframes d'origine croisée. Nos projets utilisent un seul formulaire d'autorisation, il se trouve à https://account.mail.ru/login , et lorsque nous voulons afficher le formulaire d'autorisation sur tout autre projet, par exemple, dans Mail ou dans le Cloud, iframe est réellement ajouté à la page à l'intérieur duquel cette URL s'ouvre. Cette solution nous permet de mettre à jour simultanément le formulaire lui-même sur tous les projets qui l'utilisent, et simplifie la collecte de statistiques, et améliore également l'UX de l'utilisateur, lui permettant de rester sur le même service où il était à l'origine.



Dans notre cas, la restriction des appels aux méthodes WebAuthn à partir de l'iframe nous a fait chercher des moyens de le contourner, car nous voulions nous permettre de nous connecter via WebAuthn partout où nous montrons le formulaire d'autorisation.

Qu'avons-nous fait. Pour ouvrir le formulaire d'autorisation sur tous les services, nous utilisons une petite bibliothèque, qui ne crée essentiellement qu'un iframe sur la page avec l'URL correcte et après le chargement de son contenu affiche l'iframe sur la page. Cette bibliothèque prend en charge la communication avec les iframes postMessageet l'utilise, par exemple, pour redimensionner les iframes lors du redimensionnement de son contenu.

Nous avons conçu et mis en œuvre le mécanisme suivant:

  1. dans l'application d'autorisation lors de l'utilisation de WebAuthn, nous déterminons si nous sommes maintenant ouverts à l'intérieur de l'iframe ou non;
  2. si nous sommes ouverts à l'intérieur de l'iframe, alors au lieu d'appeler l'API du navigateur WebAuthn, nous sérialisons les paramètres d'appel et les envoyons via la postMessagefenêtre parent;
  3. dans la fenêtre parente, nous désérialisons ces paramètres et appelons les méthodes WebAuthn;
  4. lorsque nous recevons une réponse, nous la sérialisons de la même manière et l'envoyons à l' postMessageintérieur d'un iframe, où nous acceptons cette réponse et effectuons un traitement supplémentaire.

Ainsi, nous avons contourné cette interdiction et réalisé la possibilité d'utiliser la même clé lors de l'autorisation dans tous les services de l'entreprise.

Automatisation des tests WebAuthn


Dans notre équipe pour tous les nouveaux projets et fonctionnalités, nous écrivons toujours des autotests d'interface utilisateur d'intégration en utilisant des solutions de type sélénium et le protocole WebDriver. Par conséquent, lors du développement de WebAuthn, la question s'est posée de savoir comment écrire l'interface utilisateur des autotests dessus.

La difficulté d'écrire de tels autotests est que le protocole WebDriver ne dispose pas encore de méthodes pour automatiser l'interaction avec WebAuthn. Et dans la norme elle-même, il n'y a toujours pas de support pour tester l'automatisation de l'API WebAuthn (mais il y a un problème sur ce sujet). Les premières idées sur la façon dont cette automatisation peut être organisée sont décrites dans un projet d' authentification Web: une API pour accéder aux informations d'identification de clé publique de niveau 2 et n'ont pas encore été publiées, sans parler d'être prises en charge ailleurs. J'ai donc dû trouver des solutions alternatives.

Parce que nous ne pouvons pas travailler avec l'implémentation native des fonctions WebAuthn dans les autotests (il n'y a pas de méthodes pour contrôler le navigateur), alors nous avons dû faire ce qui suit.

Quelque part dans l'autotest, avant d'essayer d'utiliser WebAuthn, nous corrigeons les objets hôtes globaux du navigateur et remplaçons les fonctions natives par nos implémentations. Ici, nous sauvegardons les arguments avec lesquels les fonctions natives ont été appelées dans une variable et retournons la promesse.

//    WebAuthn   
navigator.credentials.create = (options) => {
    window.credentialsCreateArgs = options;

    return new Promise((resolve, reject) => {
        window.credentialsCreateSuccess = resolve;
        window.credentialsCreateFail = reject;
    });
};

Ensuite, nous devons en quelque sorte obtenir le résultat de la fonction pour la retourner pour émuler le travail de WebAuthn dans les tests. Nous pouvons toujours renvoyer une sorte de réponse codée en dur constante.

// -    
const credentialsCreateResponse = { /* constant object */ };

window.credentialsCreateSuccess(credentialsCreateResponse);

Dans ce cas, nous devrons apprendre à notre serveur à accepter cette réponse et non à la valider, mais à la considérer automatiquement correcte.

Quels sont les inconvénients de tels tests? Dans ce cas, nous ne pourrons pas:

  • vérifier si le client forme et transfère correctement les paramètres dans les fonctions WebAuthn;
  • vérifier l'exactitude des modifications du backend lors du roulement des versions du backend.

Ainsi, de tels tests ne seront pas assez fiables, et cela ne nous convient pas.

Nous avons décidé d'aller plus loin et, en conséquence, nous avons écrit notre propre implémentation des protocoles et algorithmes FIDO2 sur Node.js, avec l'aide de laquelle nous avons réussi à verrouiller ces fonctions aussi près que possible des implémentations natives.

Autrement dit, nous avons écrit une fonction qui, sur la base des paramètres de demande, calcule la réponse pour les fonctions WebAuthn verrouillées afin que le serveur la considère comme complètement correcte.

// -    
const credentialsCreateResponse =
    calcCredentialsCreateResponse(window.credentialsCreateArgs);
 
window.credentialsCreateSuccess(credentialsCreateResponse);

En conséquence, le schéma d'opération d'autotest est le suivant:

  1. obtenir les arguments avec lesquels les méthodes WebAuthn ont été appelées;
  2. nous exécutons ces arguments via une fonction qui implémente les mêmes algorithmes qu'à l'intérieur d'authentificateurs réels;
  3. nous obtenons le résultat et le renvoyons de nos fonctions remplacées;
  4. tout le reste du code de notre service traite ces réponses dans le mode habituel et, par conséquent, tout le comportement du service ne diffère pas de son comportement pour les utilisateurs réels.

Les sources d'un tel autotest et l'implémentation de l'authentificateur le plus secret sont dans le référentiel github , vous pouvez commencer et étudier leur travail plus tard. Lors de l'écriture de l'authentificateur, nous n'avons été guidés que par la spécification w3.org et la documentation Node.js.

Le présent et l'avenir de WebAuthn


Donc, ce que nous avons en ce moment.

Nous avons lancé une entrée de clé électronique pleinement opérationnelle fin septembre 2019. Maintenant, nous n'annonçons pas ce type d'entrée, et il n'est pas utilisé très activement - moins d'une centaine d'utilisateurs uniques par jour. Mais nous sommes convaincus qu'avec le temps, leur nombre ne fera qu'augmenter et, tôt ou tard, l'enregistrement électronique des clés deviendra l'un des principaux types de connexion à votre compte.

Ce qui nous empêche de promouvoir activement une telle entrée, c'est que WebAuthn lui-même n'est toujours pas suffisamment fiable et stable dans les navigateurs, et il existe de nombreuses nuances concernant son support et son fonctionnement.

Pourquoi WebAuthn est-il désormais une fonctionnalité qui n'est pas destinée à un large public?

Le facteur le plus fondamental ici est qu'il nécessite que l'utilisateur ait un appareil spécial - une clé électronique. Maintenant, le besoin n'est pas si fortement ressenti par les utilisateurs. De nombreux utilisateurs ne sont pas conscients de leur existence. Mais au fil du temps, lorsque de plus en plus de services commenceront à prendre en charge cette façon de se connecter, le nombre d'utilisateurs avec de telles clés commencera également à augmenter.

Un bond en avant significatif dans la popularité de WebAuthn peut se produire lorsque les ingénieurs de Google achèvent le développement et testent la possibilité d'utiliser les smartphones sur Android et iOS comme clés électroniques physiques externes pour WebAuthn et ouvrent cette opportunité pour tous les services Internet. Dans ce cas, chaque propriétaire d'un smartphone moderne aura essentiellement la possibilité de l'utiliser comme clé WebAuthn et le nombre d'utilisateurs de WebAuthn augmentera considérablement. Cette fonctionnalité n'est désormais disponible que pour les utilisateurs du service de messagerie Google.



Sinon, comment pouvez-vous utiliser WebAuthn?


Mail.ru utilise maintenant WebAuthn comme alternative aux mots de passe pour entrer dans le compte. Mais essentiellement WebAuthn peut être utilisé comme n'importe lequel des facteurs d'autorisation. Il peut être utilisé comme au lieu du premier facteur dans l'authentification à un facteur. Donc, au lieu du second - comme une protection supplémentaire par mot de passe avec deux facteurs. De plus, une confirmation via une clé électronique peut être utilisée, par exemple, lors de la restauration de l'accès à un compte si l'utilisateur a perdu ou oublié son mot de passe.

WebAuthn peut être utilisé comme mesure de sécurité supplémentaire lors de la modification des paramètres critiques de votre compte. Imaginez à quel point c'est pratique - vous allez dans les paramètres de profil de votre service préféré, et vous n'avez pas besoin de vous souvenir et d'entrer un mot de passe pour les changer! Placez simplement votre doigt sur le scanner d'empreintes digitales et vous serez transmis.

Vous pouvez trouver encore plus de scénarios différents pour utiliser WebAuthn dans cet article Medium .

Questions et réponses populaires


Où puis-je acheter une clé électronique?


Jusqu'à présent, il n'y a pas beaucoup d'endroits en Russie où vous pouvez acheter des clés électroniques compatibles avec les protocoles FIDO2. La plupart des fournisseurs ne les vendent qu'en vrac, par lots de 10 ou plus. Vous pouvez acheter des clés électroniques pièce par pièce dans les magasins suivants:


En outre, ces clés peuvent être commandées dans des magasins en ligne conviviaux, par exemple sur Amazon . Dans cet article, il existe des caractéristiques comparatives des modèles de commutateurs électroniques 10 avec des liens vers les magasins où ils peuvent être achetés.

Et si je perds ma clé électronique?


À l'aide de clés électroniques, vous devez les traiter avec la même attention qu'avec les clés de l'appartement ou de la voiture. Si nous perdons les clés de l'appartement, nous changeons généralement la serrure et obtenons de nouvelles clés. Il en va de même pour les clés électroniques: si elles sont perdues, vous devez les supprimer immédiatement de tous les comptes où elles étaient liées et attacher un nouvel authentificateur à tous les comptes.

En cas de perte de la clé électronique principale, vous devez disposer de plusieurs méthodes d'authentification supplémentaires. Par exemple, en utilisant l'application de génération de codes, ou en utilisant une clé de rechange qui peut être stockée dans un endroit spécialement protégé: dans un coffre-fort ou dans une cellule de banque.

Que dois-je faire si quelqu'un d'autre a accès à ma clé électronique?


Si l'authentification à deux facteurs est incluse dans votre compte et que la clé électronique n'est qu'un des facteurs, alors dans ce cas, votre compte sera protégé contre le piratage. À moins que l'attaquant n'ait accès au deuxième facteur.

Si la clé électronique est le seul facteur suffisant pour entrer dans le compte, même dans ce cas, l'attaquant doit connaître le nom du compte dans lequel cette clé électronique est enregistrée. Ces informations ne sont pas stockées à l'intérieur de la clé électronique, et donc une clé électronique accidentellement perdue avec un haut degré de probabilité sera complètement inutile pour un passant qui l'a trouvée.

Cependant, il existe des schémas dans lesquels les clés électroniques peuvent être utilisées en remplacement non seulement d'un mot de passe, mais également d'une connexion. Dans ce scénario, le serveur fournit uniquement des informations d'identification lors de la demande d'informations d'identification.originet les informations d'identification elles-mêmes sont entièrement stockées dans l'authentificateur. Dans ce cas, la clé électronique perdue peut déjà être facilement utilisée pour entrer dans votre compte, et alors vous devriez faire plus attention à votre authentificateur. Pour la protection dans de tels scénarios, vous pouvez utiliser des clés électroniques avec des mesures de sécurité supplémentaires, par exemple des clés, pour l'activation desquelles vous devez saisir un code PIN.

Dans tous les cas, dès que vous constatez la perte de votre clé, vous devez immédiatement la détacher de tous les comptes de tous les services, où vous pouvez l'utiliser pour entrer. C'est pourquoi tous les services devraient permettre de gérer une liste d'authentificateurs liés. Plus vous remarquerez la perte rapidement, moins les attaquants disposeront de temps pour accéder à vos données.

Maintenant, mes données biométriques seront stockées sur les serveurs Mail.ru/Google/Microsoft?


Lorsque WebAuthn fonctionne avec des authentificateurs intégrés (par exemple, en utilisant Touch ID sous Mac OS), seuls le capteur correspondant et le système d'exploitation lui-même ont accès à vos données biométriques. Le service Web ne reçoit et ne traite aucune information biométrique; il fonctionne uniquement avec la clé cryptographique publique et avec les données signées avec la clé privée.

Et sur le serveur lui-même, seules les informations sur la clé publique sont stockées. Par conséquent, WebAuthn n'utilise en aucune façon vos données biométriques pour travailler avec des authentificateurs intégrés.

Conclusion


Comme nous l'avons découvert, WebAuthn présente de nombreux avantages importants par rapport aux mots de passe:

  • lors de l'utilisation de WebAuthn, il n'est pas nécessaire de se souvenir et d'entrer les mots de passe;
  • WebAuthn - , ;
  • WebAuthn ;
  • WebAuthn — .

Cependant, les mots de passe ne doivent pas être supprimés. Une clé physique peut toujours être volée ou perdue, tout comme un mot de passe. Mais les mots de passe ont un avantage important. Tant qu'ils ne sont stockés que dans la tête, ils ne pourront pas les reconnaître à l'insu du propriétaire.

En résumé, je tiens à dire que la technologie WebAuthn est une technologie très prometteuse qui change un élément aussi fondamental et important du fonctionnement de tous les services Web modernes que l'authentification. C'est également une technologie assez récente et les utilisateurs n'y sont pas encore habitués. Mais il est en notre pouvoir de le rendre plus populaire et plus pratique.

J'espère que notre expérience de la mise en œuvre de WebAuthn dans Mail.ru Mail vous aidera à le soutenir dans vos services, et ensemble, nous rendrons Internet plus sûr et plus moderne!

Matériaux additionnels



All Articles