Chaque mot de passe a besoin d'un partenaire discret

Les « passkeys » renforcent considérablement la sécurité de l'authentification, mais elles ne résolvent pas tous les problèmes liés à l'identité. Dans ce tutoriel, vous découvrirez pourquoi l'inscription et la récupération de compte restent complexes, comment l'authentification silencieuse comble ces lacunes, et comment mettre en place un processus complet à l'aide de la Verify API. 

Les mots de passe constituent le plus ancien bug non corrigé des logiciels, et les clés d’accès constituent la première solution qui supprime le secret partagé au lieu de le déplacer. Toutes les solutions antérieures, des codes à usage unique aux liens magiques, ne faisaient que déplacer ce secret vers un endroit mieux protégé. Si vous souhaitez découvrir l’historique complet de cette évolution, ainsi que les deux étapes qui permettent à une clé d’accès de fonctionner, j’ai rédigé un article à ce sujet dans « Les clés d’accès : les principes fondamentaux ». 

Les « passkeys » connaissent un essor fulgurant. En remplaçant le mot de passe par une paire de clés publique/privée, la clé privée ne quittant jamais l'appareil de l'utilisateur et le serveur ne conservant que la clé publique, elles rendent le phishing inefficace par nature. Le navigateur refusera tout simplement d'utiliser la clé sur un site non autorisé, et une base de données d'identifiants volés ne deviendra alors qu'une liste de clés publiques sans aucune valeur. 

Malgré tous ces atouts, les mots de passe laissent toutefois deux failles. Elles ne permettent pas de savoir qui se présente à la porte lors de la toute première inscription, et elles ne permettent pas à un utilisateur légitime de rentrer s’il a perdu sa dernière clé d’accès. Ces deux failles se situent précisément là où l’authentification silencieuse de Vonage : elle vérifie la possession d’un numéro de téléphone à l’aide de la carte SIM et du réseau de l’opérateur, sans code à saisir et sans rien qu’un hameçonneur puisse intercepter. 

Deux facteurs résistants au phishing et sans friction, chacun couvrant l'angle mort de l'autre. Voyons pourquoi ils s'accordent si bien, puis construisons le flux à l'aide de l' Verify API v2. 

Fonctionnement des clés d'accès et de WebAuthn 

Les clés d'accès sont des identifiants WebAuthn. Lors de l’enregistrement, l’appareil génère une paire de clés au sein d’un matériel sécurisé et envoie la clé publique au serveur. Lors de la connexion, le serveur émet un défi aléatoire, l’appareil le signe après un geste biométrique ou la saisie d’un code PIN, puis le serveur vérifie la signature. Une simple pression du pouce constitue déjà une authentification multifactorielle : quelque chose que vous possédez (l’appareil) et quelque chose qui vous est propre (le geste). Point crucial : le navigateur ne propose une clé d’accès que sur le domaine pour lequel elle a été créée ; ainsi, ce n’est plus l’utilisateur qui décide si une page de connexion est authentique. 

Authentification silencieuse vérifie l'identité d'un utilisateur grâce à sa carte SIM. Votre backend lance une vérification via l’API Verify v2, reçoit une URL de vérification (check_url), et l’appareil de l’utilisateur ouvre cette URL via sa connexion mobile. L’opérateur vérifie directement dans ses propres registres que la requête provient bien de l’appareil associé à ce numéro de téléphone, puis renvoie une réponse GSM confirmant l’authentification. Aucun SMS n’est envoyé, aucun code à six chiffres n’est saisi, et rien n’apparaît à l’écran qui puisse permettre à un pirate d’exploiter l’ingénierie sociale auprès de l’utilisateur. L’authentification s’effectue directement entre l’opérateur et l’appareil mobile, ce qui élimine complètement le scénario classique de phishing par mot de passe à usage unique (OTP). 

Remarquez la symétrie : 

• Une clé d'accès atteste que vous êtes en possession d'une clé privée associée à votre service. 

• L'authentification silencieuse permet de prouver la possession d'une carte SIM associée à un numéro de téléphone. 

Aucun de ces deux facteurs ne révèle jamais de secret à l'utilisateur ; par conséquent, aucun ne lui fournit de secret qu'il pourrait divulguer. 

Quand les mots de passe ont besoin d'un coup de main 

Il est utile de noter que l'inscription, la connexion et la récupération de mot de passe ne constituent pas la même question posée trois fois. L'inscription pose la question « Qui est cette personne ? », la connexion demande « Est-ce bien la même personne que celle qui s'est inscrite ? », et la récupération de mot de passe demande « Est-ce vraiment cette personne, maintenant que l'élément qui le prouvait a disparu ? ». Les clés d'accès apportent une excellente réponse à la question de la connexion, mais aucune réponse aux deux autres. 

Le problème du « jour 1 » 

Une clé d’accès ne peut que prouver que la personne qui se connecte est bien celle qui s’est inscrite. Elle ne donne aucune indication sur l’identité de la personne qui s’est inscrite. Au tout début, il n’y a pas encore de clé d’accès ; par conséquent, la plupart des inscriptions sans mot de passe se rabattent sur le maillon le plus faible de l’ensemble du système : une adresse e-mail, non vérifiée ou vérifiée via un lien qui peut lui-même faire l’objet d’une tentative d’hameçonnage. Si un pirate crée l’account victim@example.com avant la victime et y associe sa propre clé d’accès, vous êtes confronté à un problème de prise de contrôle de l’account avant même que votre utilisateur ne se soit connecté. 

Le fait de lier l'inscription à un numéro de téléphone vérifié en arrière-plan change la donne. Le compte est créé en fonction d'un numéro dont l'opérateur vient de confirmer qu'il est bien actif sur cet appareil, et ce n'est qu'à ce moment-là que la procédure de génération de la clé d'accès est lancée. La clé d'accès prolonge désormais de manière cryptographique une identité que vous avez réellement vérifiée, plutôt qu'une identité que l'utilisateur s'est contenté de saisir. 

Le problème du « dernier appareil » 

La deuxième solution, c'est la récupération. Un utilisateur disposant d’une clé d’accès liée à un seul appareil risque de se retrouver bloqué dès qu’il perd son téléphone, et même les clés d’accès synchronisées partent du principe que l’utilisateur a toujours accès à son compte sur la plateforme. La plupart des produits se rabattent sur un lien magique envoyé par e-mail, qui réintroduit discrètement tout ce que les clés d’accès avaient supprimé : un jeton au porteur, stocké dans une boîte de réception, protégé par un mot de passe. 

Silent Auth vous offre une solution de récupération présentant le même niveau de sécurité que le dispositif qu’elle permet de récupérer. Nouveau téléphone, même numéro : l’opérateur certifie la carte SIM, l’utilisateur réenregistre une clé d’accès, et à aucun moment un code ne transite par un canal susceptible d’être surveillé par un pirate. 
Le flux combiné 

Voici le cycle de vie complet : 

1. Inscription : Verify your phone number with Silent Auth, create your account, then register your first access key. 

1. À chaque connexion suivante : un mot de passe uniquement. Un seul geste, aucun échange de données avec l'opérateur, fonctionne sur n'importe quel appareil, y compris les ordinateurs de bureau. 

1. Récupération ou nouvel appareil sans synchronisation : Effectuez à nouveau l'authentification silencieuse, puis enregistrez une clé d'accès de remplacement. 

1. Étape facultative : Pour les actions à haut risque (versement, modification de l'adresse e-mail, ajout d'un nouveau mot de passe à partir d'un navigateur non reconnu), effectuez une vérification Silent Auth en arrière-plan en tant que deuxième facteur indépendant. 

Les « passkeys » gèrent le quotidien ; « Silent Auth » s'occupe des cas particuliers. Écrivons maintenant les parties intéressantes. 

Conditions préalables 

• A Account API Vonage. Si vous n'en avez pas encore, vous pouvez <s'inscrire></s'inscrire> dès aujourd'hui et commencer à développer vos applications grâce à un crédit gratuit. 

• Votre application a été enregistrée auprès du registre du réseau pour une utilisation en production (pendant la phase de développement, vous pouvez utiliser l'environnement de test ; vous trouverez plus d'informations à ce sujet ci-dessous). 

• Un backend capable de maintenir une session ; les extraits de code ci-dessous utilisent simplement curl et le JavaScript du navigateur, vous pouvez donc les adapter à la pile technologique de votre choix. 

• Un téléphone équipé d'une carte SIM et d'un forfait de données mobiles pour tester la phase « Silent Auth ». 

Étape 1 : Verify discrètement le numéro lors de l'inscription 

Lorsqu'un nouvel utilisateur saisit son numéro de téléphone, votre backend lance une procédure de vérification. C'est dans le tableau « workflow » que réside toute la magie : « silent_auth » en premier lieu, avec un SMS de secours pour les cas où Silent Auth ne peut pas fonctionner. 

 

curl -X POST https://api.nexmo.com/v2/verify \ 

  -H "Authorization: Bearer $JWT" \ 

  -H "Content-Type: application/json" \ 

  -d '{ 

    "brand": "ACME Inc", 

    "workflow": [ 

      { "channel": "silent_auth", "to": "447700900000" }, 

      { "channel": "sms", "to": "447700900000" } 

    ] 

  }' 

La réponse contient un request_id et, pour l’authentification silencieuse, un check_url: 

{ 

  "request_id": "b3a2f4d0-1234-4d6e-9f00-example00000", 

  "check_url": "https://api-eu-3.vonage.com/v2/verify/b3a2f4d0.../silent-auth/redirect" 

} 

Remettez le check_url au client, et demandez à l'appareil de l'ouvrir via sa connexion mobile. C'est la seule exigence impérative de Silent Auth : si la requête est envoyée via le Wi-Fi, l'opérateur ne la voit jamais et la vérification échoue. Les bibliothèques client Vonage pour iOS et Android existent précisément pour forcer l'utilisation des données mobiles, même lorsque le Wi-Fi est activé ; utilisez-les donc plutôt que de développer votre propre solution. 

L'appareil suit une courte chaîne de redirections vers le réseau de l'opérateur et renvoie un code, que votre client transmet à votre backend, lequel le transmet à son tour à Verify : 

curl -X POST https://api.nexmo.com/v2/verify/$REQUEST_ID \ 

  -H "Authorization: Bearer $JWT" \ 

  -H "Content-Type: application/json" \ 

  -d '{ "code": "'$CODE'" }' 

Un "status": "completed" signifie que l’opérateur s’est porté garant de la carte SIM. L’utilisateur a été vérifié et, voici la partie qui mérite d’être savourée : , il n’a rien vu de tout cela. Aucun code ne lui a été envoyé, il n’a rien saisi. De son point de vue, il a simplement saisi un numéro de téléphone et a été connecté automatiquement. 

Au cours du développement, ajoutez "sandbox": true à l'entrée du workflow et utilisez le Network Registry Playground, afin de pouvoir tester l'ensemble du flux sans couverture de l'opérateur. 

Étape 2 : Enregistrer la première clé d'accès 

C'est maintenant, et uniquement maintenant, que vous devez créer l'Account et lancer immédiatement la procédure d'enregistrement WebAuthn. L'API native du navigateur ne nécessite plus aucune dépendance aujourd'hui : 

// The server generated these options, including a random challenge 

// and the user object: { id: userHandle, name: phoneOrEmail } 

const options = PublicKeyCredential.parseCreationOptionsFromJSON(optionsJSON); 

 

// The OS prompts for Touch ID / Face ID / Windows Hello and mints 

// the key pair inside secure hardware. The private key never leaves. 

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

 

await fetch("/registration", { 

  method: "POST", 

  headers: { "Content-Type": "application/json" }, 

  body: JSON.stringify({ credential: credential.toJSON() }), 

}); 

Deux paramètres côté serveur permettent de transformer un identifiant classique en clé d'accès. Ces paramètres nécessitent une identifiant (resident_key: "required") afin que la connexion puisse s'effectuer sans nom d'utilisateur, et exigent une une vérification de l’utilisateur pour le geste biométrique. Sachez que l’option `user_verification` se contente de demander le geste au navigateur ; c’est votre étape de vérification sur le serveur qui doit également vérifier l’indicateur « utilisateur vérifié » dans la réponse de l’authentificateur, sinon un client altéré peut contourner la vérification biométrique et réduire discrètement votre connexion multifactorielle à une connexion à facteur unique. Une fois cette vérification effectuée, comparez la réponse au défi que vous avez émis, stockez la clé publique, et l’Account dispose désormais d’un identifiant résistant au phishing, associé à un numéro de téléphone vérifié par l’opérateur. 

Remarque concernant la conception : le numéro de téléphone que vous avez Verify constitue une étiquette parfaitement lisible par l'utilisateur pour la clé d'accès (user.name dans les options de création), et la spécification WebAuthn mentionne explicitement les numéros de téléphone aux côtés des adresses e-mail et des noms d'utilisateur précisément dans ce but. Mais ne l’utilisez jamais comme identifiant utilisateur (user.id) ; celui-ci doit rester un identifiant aléatoire opaque. 

Étape 3 : Connectez-vous uniquement à l'aide de la clé d'accès, et rien d'autre

La connexion quotidienne n'implique jamais la Verify API. L'utilisateur appuie sur un bouton, le navigateur affiche la fenêtre de sélection de compte, un simple geste suffit pour valider la requête du serveur, et le tour est joué. 

À ce stade, vous pourriez vous demander : pourquoi ne pas utiliser Silent Auth à chaque connexion également, comme couche de sécurité supplémentaire ? La réponse est simple : parce que vous paieriez alors pour une couverture dont vous n’avez pas besoin et perdriez celle dont vous avez besoin. Une connexion par clé d’accès prouve déjà la possession d’un appareil enregistré ainsi qu’une donnée biométrique récente, et elle fonctionne sur les ordinateurs de bureau, en Wi-Fi et même dans un sous-sol sans réseau — exactement là où une vérification par l’opérateur ne peut pas atteindre. Chaque vérification « Silent Auth » coûte également un aller-retour sur le réseau (ainsi que des frais par vérification). Cela ne pose pas de problème pour certains moments clés du cycle de vie, mais cela devient un fardeau notable si cette vérification est appliquée à chaque connexion. En d’autres termes, réservez la vérification de l’opérateur aux moments où la clé d’accès ne peut pas « parler ». 

Étape 4 : Rétablissement : la même porte que le premier jour 

Lorsqu'un utilisateur perd sa dernière clé d'accès, la procédure de récupération se résume à l'étape 1, suivie à nouveau de l'étape 2 : vérifier en arrière-plan le numéro qu'il a enregistré, ouvrir une session de récupération temporaire et lui permettre de générer une nouvelle clé d'accès. Le workflow avec la solution de secours par SMS gère déjà les cas délicats, comme celui d’un utilisateur dont le nouveau téléphone dispose d’une carte SIM mais qui utilise actuellement un ordinateur de bureau : dans ce cas, Verify passe simplement à l’étape suivante du workflow via le canal suivant. 

Il convient d'être honnête quant à ce compromis, car il n'existe pas de solution miracle en matière de vérification des utilisateurs. : RrLa récupération liée à un numéro de téléphone suit le cycle de vie de ce dernier. Les Numbers sont réutilisés, et la fraude par échange de carte SIM existe ; c’est pourquoi la vérification effectuée par Silent Auth, qui consiste à consulter les registres de l’opérateur pour détecter les changements récents de carte SIM, constitue un niveau de sécurité nettement supérieur à celui d’un code SMS, et pourquoi vous devriez considérer la récupération comme une occasion propice à une vigilance accrue (alertez tous les autres canaux dont vous disposez, retardez les actions à forte valeur ajoutée et consignez l’événement). 

Pourquoi cette association fonctionne-t-elle ? 

En prenant un peu de recul, on constate que l'image est d'une clarté agréable : 

Tout système d’authentification est confronté à un problème de démarrage et à un problème de récupération, et la plupart des solutions basculent discrètement vers un canal vulnérable au phishing précisément à ces deux moments-là. L’association des clés d’accès à l’authentification silencieuse permet de maintenir l’ensemble du cycle de vie sur des facteurs qui ne révèlent jamais de secret à l’utilisateur. Le navigateur vérifie l’origine, l’opérateur vérifie la carte SIM, et l’utilisateur n’est jamais amené à évaluer un élément qu’un hameçonneur pourrait falsifier, ce qui signifie qu'il n'y a jamais de secret dont l'utilisateur pourrait être amené à se dévoiler. 

Et c'est bien là le dispositif annoncé par le titre : « Silent Auth » est l'associé silencieux. Il met en place la fiducie qui permet de lancer l'entreprise, intervient lorsque celle-ci a besoin d'être renflouée et reste dans l'ombre le reste du temps, tandis que « Passkey » gère les opérations au quotidien. 

Conclusion 

Si vous souhaitez approfondir l'un ou l'autre de ces aspects, le guide « Silent Authentication » traite de la couverture et de l'enregistrement dans le registre réseau, tandis que le tutoriel « Premiers pas avec l’authentification silencieuse » vous guide tout au long du check_url processus de bout en bout avec un backend Node.js, tandis que l’ article sur les bonnes pratiques aborde en détail la conception des workflows de repli. 

Avez-vous associé les clés d'accès à l'authentification réseau, ou comptez-vous le faire ? Nous serions ravis de savoir comment cela se passe. Rejoignez-nous sur la Slack de la communauté Vonage  et sur GitHub, ou suivez-nous sur X pour rester informé, et si vous êtes prêt à vous lancer, <sign-up></sign-up> et commencez dès aujourd’hui avec un crédit gratuit.