Des passkeys à côté des mots de passe, sans perdre personne
Comment EAuth propose passkey et mot de passe sur une même page, pourquoi le mot de passe reste, et ce contre quoi une passkey protège là où il ne peut rien.
Chaque application qui se connecte via EAuth propose les passkeys, à côté du mot de passe, sur la même page. Personne n'est obligé de changer, personne n'a besoin qu'on lui explique ce qu'est une passkey avant de pouvoir s'en servir, et le mot de passe ne disparaît pas. Cet article porte sur la cohabitation des deux, parce que c'est là que la plupart des déploiements de passkeys échouent.
Une passkey, en un paragraphe
Une passkey est une paire de clés. La moitié privée reste sur le téléphone, l'ordinateur portable ou la clé de sécurité de la personne, protégée par le verrouillage de l'appareil : empreinte digitale, visage ou code PIN. La moitié publique est enregistrée auprès du site. Se connecter, c'est recevoir un défi du site et le faire signer par l'appareil, une fois que la personne l'a déverrouillé. Le site ne voit jamais de secret, il n'y a donc rien à faire fuiter de notre base de données, et le navigateur lie la passkey à eauth.me : une copie de la page de connexion sur un autre domaine n'obtient rien que la vraie accepterait. Cette dernière propriété, un mot de passe ne peut pas l'avoir : la personne qui tape son mot de passe dans une copie convaincante de la page l'a donné ; une passkey refuse de fonctionner là.
Une page, deux entrées
La page de connexion d'EAuth affiche les champs e-mail et mot de passe et, en dessous, « Sign in with a passkey ». C'est toute l'interface. Le bouton n'apparaît qu'après que le script de la page a vérifié que le navigateur sait utiliser une passkey : un navigateur qui ne le sait pas n'affiche jamais un bouton qui ne fait rien.
Derrière, la page demande au navigateur la médiation conditionnelle. Le champ e-mail est marqué username webauthn, et un navigateur qui détient une passkey pour eauth.me la propose parmi les suggestions de ce champ, comme il propose un mot de passe enregistré. Un navigateur qui n'en détient aucune n'affiche rien de plus. Personne ne saisit d'adresse d'abord : la passkey que choisit la personne désigne le compte. Celui qui a une passkey l'utilise d'un geste ; celui qui n'en a pas voit une page de connexion normale.
Il n'y a pas de mode « sans mot de passe » à activer, ni de fenêtre à chaque visite pour vous demander si vous voulez en créer une. Une fenêtre de ce genre apprend aux gens à fermer les boîtes de dialogue sans les lire, l'inverse de ce dont la sécurité a besoin.
Où l'on crée une passkey
Sur la page du compte, sous Security, à côté du second facteur. En ajouter une demande d'abord le mot de passe. Une passkey est une porte d'entrée qui survit à un changement de mot de passe : un navigateur que quelqu'un a laissé connecté ne doit pas suffire pour en laisser une derrière soi, et les mauvais mots de passe y sont comptés, cinq par compte en quinze minutes. Ensuite, l'appareil crée la clé. La personne peut lui donner un nom, « MacBook » ou « iPhone », pour que la liste veuille encore dire quelque chose un an plus tard ; sans nom, elle prend celui du navigateur et de la plateforme. Chaque ajout est signalé par mail à l'adresse du compte, avec la marche à suivre si ce n'était pas la personne elle-même.
En supprimer une, c'est un bouton et une confirmation. Il n'y a pas de minimum : une personne peut supprimer sa dernière passkey, puisqu'elle a toujours son mot de passe.
Les passkeys créées sur un téléphone ou un ordinateur portable sont en général synchronisées par la plateforme, celle d'Apple ou de Google, vers les autres appareils de la personne. EAuth enregistre si une passkey est synchronisée et l'indique sur la page du compte, parce que cela change ce que signifie la perte d'un appareil : une passkey synchronisée y survit, une passkey sur une clé matérielle non. L'export des données d'une personne qu'une application produit pour une demande RGPD porte la même mention.
Une clé matérielle tient aussi un compteur qui augmente à chaque utilisation. Quand il n'augmente pas, la clé a peut-être été copiée, et EAuth ne se contente pas de refuser cette connexion : il supprime la passkey, puisqu'une copie continuerait de fonctionner, et invite la personne à se connecter avec son mot de passe et à en ajouter une nouvelle. Les passkeys synchronisées ne tiennent pas de compteur et ne sont pas traitées comme des copies.
Pourquoi le mot de passe reste
Deux raisons, et la nostalgie n'en fait pas partie.
Les appareils d'une personne changent. Un nouveau téléphone où le compte de la plateforme n'est pas encore connecté, un portable emprunté, un poste d'entreprise au navigateur verrouillé : à chacun de ces moments, la passkey n'est pas sous la main. Le mot de passe est alors la porte d'entrée, et le second facteur s'y applique toujours.
La récupération doit exister. Avec le mot de passe conservé, perdre une passkey ne fait rien perdre : le compte a toujours son mot de passe, et un mot de passe oublié se réinitialise par un lien envoyé à l'adresse confirmée, comme avant. Si le mot de passe disparaissait, la récupération reposerait sur ce seul lien, plus faible que l'un comme l'autre. Le garder fait de la passkey un pas en avant, pas un pas de côté.
Ce qu'elle ne fait pas
Une passkey n'est pas un second facteur pour le mot de passe. Une passkey dont l'appareil a vérifié la personne, par un PIN, une empreinte ou un visage, se suffit à elle-même : quelque chose qu'elle possède, et quelque chose qu'elle sait ou qu'elle est. Une passkey qui n'a enregistré qu'un contact, comme le font certaines clés de sécurité, compte pour un facteur, et un compte qui a activé un second facteur se voit demander son code, comme après un mot de passe. Se connecter avec le mot de passe demande toujours le code si la personne en a configuré un. Les deux chemins sont séparés.
Une passkey ne remplace pas non plus les limites du formulaire de mot de passe. Un attaquant qui ignore la passkey et devine des mots de passe se heurte aux mêmes limites qu'avant : vingt mauvais mots de passe par compte en quinze minutes, d'où qu'ils viennent, cinq depuis une même adresse, comptés avant que le mot de passe soit vérifié. Les requêtes de passkey partagent la limite par adresse de trente requêtes de connexion par minute, donc une passkey à côté du formulaire n'élargit rien.
Pour les développeurs
Rien ne change dans votre intégration : aucun réglage, aucun appel au SDK. Un utilisateur qui se connecte avec une passkey reçoit le même code d'autorisation et le même ID token que celui qui a utilisé un mot de passe. Le token n'indique pas lequel des deux a servi, vous ne pouvez donc pas, aujourd'hui, traiter différemment les connexions par passkey. C'est une limite, et je préfère la nommer plutôt que de vous laisser chercher un claim qui n'existe pas.
Un compte EAuth appartient à une seule application. Une personne qui utilise deux applications a deux comptes et ajoute une passkey à chacun. Comme chaque passkey appartient à eauth.me, le navigateur peut proposer les deux sur l'une ou l'autre page de connexion ; celle de l'autre application est refusée avec un message qui le dit, et aucune connexion n'a lieu. Notre console pour développeurs et notre tableau de bord se connectent par la même page, les développeurs y ont donc aussi les passkeys.
Sources
- Web Authentication: An API for accessing Public Key Credentials, Level 3, W3C, consulté le
- Bootstrapping, passkeys.dev, consulté le
- Multifactor Authentication Cheat Sheet, OWASP, consulté le
Écrit par Samuel Krauss, Founder. Classé sous eauth, passkeys, security, webauthn.
Traduit de l’anglais. Lire l’original anglais