Le schéma « l’e-mail fait office d’authentification »

• Certains utilisateurs, au lieu de se souvenir de leur mot de passe ou de le gérer, utilisent à chaque fois la procédure « mot de passe oublié » comme méthode de connexion
• Le flux réel consiste à recevoir un lien de récupération par e-mail depuis la page de connexion, à saisir un mot de passe temporaire, puis à répéter le même processus lors de la visite suivante
• Cette habitude relève moins d’une stratégie de sécurité consciente que d’un comportement appris qui s’est installé avec le temps
• Même des améliorations comme les gestionnaires de mots de passe et l’authentification en deux étapes ou multifacteur peuvent être perçues par l’utilisateur comme une augmentation des frictions plutôt que comme un renforcement de la sécurité
• La conception des systèmes doit partir du principe que les utilisateurs répètent certains comportements, et les guider naturellement vers de meilleures pratiques d’utilisation

---

La récupération de mot de passe utilisée comme connexion

• Certains utilisateurs, lorsqu’ils se connectent à un compte en ligne, ne saisissent pas leur mot de passe et répètent à chaque fois la procédure de récupération
  • Ils arrivent sur la page de connexion
  • Ils cliquent sur « I forgot my password »
  • Ils vont dans leur boîte e-mail
  • Ils cliquent sur le lien de récupération
  • Ils saisissent un mot de passe temporaire dont ils ne se souviendront pas
  • Puis ils répètent le même processus par la suite
• Lorsqu’on leur demande pourquoi ils font cela, ils ne savent pas répondre ou disent ne jamais y avoir réfléchi
• Ce comportement n’est pas une stratégie de connexion décidée le matin même, mais plutôt une procédure répétitive qui s’est ancrée avec le temps

Les frictions que les améliorations de sécurité créent pour l’utilisateur

• Cette méthode fonctionne comme une solution à faible effort qui évite à l’utilisateur de mémoriser une phrase de passe
• Les gestionnaires de mots de passe, l’usurpation d’identité, l’authentification en deux étapes et multifacteur, ainsi que l’obsolescence du modèle nom d’utilisateur/mot de passe, sont déjà des sujets largement discutés
• De meilleures procédures de sécurité ajoutent souvent des obstacles et des frictions, ce qui peut les rendre difficiles à adopter naturellement par les utilisateurs
• Les concepteurs doivent tenir compte des comportements appris des utilisateurs et créer des parcours permettant, avec le temps, de migrer vers de meilleures pratiques d’utilisation

[GN⁺]

Avis sur Hacker News

• Le compte e-mail est le plus petit dénominateur commun de l’authentification en ligne. Le téléphone mobile est aussi un concurrent sérieux, mais on peut le perdre ; les numéros de téléphone sont plus répandus et durent plus longtemps, mais leur niveau de sécurité est bien inférieur à celui des comptes chez les grands fournisseurs d’e-mail.
  Si l’on veut concevoir un « système d’authentification imaginaire pour Internet », il faut commencer par regarder la récupération de compte. Si, quand on perd son super authentificateur, la réponse est « eh bien, plus d’accès » ou « un panel de pairs garantit votre identité », alors ce système ne peut fonctionner qu’avec des formes de vie intelligentes imaginaires comme utilisateurs, pas avec des humains.

  • C’est la principale raison pour laquelle je m’oppose depuis des années à la blockchain/crypto. Le modèle « si vous perdez la clé, vous perdez aussi le portefeuille » est fondamentalement incompatible avec les utilisateurs réels.
    Les humains doivent pouvoir se remettre de leurs erreurs.
  • Une identité numérique émise par l’État pourrait résoudre une grande partie de ce problème. Elle aurait ses propres problèmes, bien sûr, mais confier l’identification des personnes à l’État me paraît plus précieux et moins risqué que les verrouillages de compte par des acteurs comme Google.
  • Malheureusement, même chez de grands fournisseurs d’e-mail comme Google, « eh bien, plus d’accès » est un schéma courant. Les personnes définitivement exclues de leur compte après avoir perdu leur téléphone ou se l’être fait voler l’illustrent bien.
  • Même pour un « compte e-mail chez un grand fournisseur », il faut ajouter la réserve suivante : « le compte a été suspendu sans raison, il n’existe aucun moyen de faire appel, et on ne vous dit même pas pourquoi il a été suspendu ».
  • Le modèle où un panel de pairs garantit l’identité d’une personne est un problème de conception intéressant. S’il existait un système commun permettant de recomposer, sur instruction des parties concernées, un secret d’authentification correctement réparti, on pourrait rendre cela assez fluide.
    Peut-on le faire fonctionner aussi pour des humains ordinaires ? Je pense qu’on a assez de créativité pour le concevoir.

• Notre service est un business assez léger, donc les utilisateurs n’utilisent leur compte que par commodité. La solution sur laquelle on s’est fixés est la suivante : l’utilisateur saisit son e-mail, on lui envoie un code de vérification par e-mail, et lorsqu’il saisit le code, on émet un cookie très longue durée qui le laisse connecté quasiment indéfiniment.
  Peu importe qu’un compte existe déjà ou non : si c’est une nouvelle adresse e-mail, on crée un nouveau compte. Il arrive que des utilisateurs ayant plusieurs adresses créent un nouveau compte par erreur, mais les taux de conversion à l’inscription et à la connexion se sont nettement améliorés, donc c’est acceptable. La durée de validité du code et le nombre de tentatives nécessitent une analyse de risque, et il vaut mieux utiliser un mécanisme de verrouillage si possible. Si votre service n’est pas très critique, je recommande cette stratégie. iOS Mail prend désormais aussi en charge ce genre de mécanisme, comme la fonctionnalité de codes à usage unique dans Messages, donc c’est assez pratique pour certains utilisateurs.

  • D’après les données que j’ai vues, cette approche est de loin la meilleure pour maximiser le chiffre d’affaires e-commerce.
    Il ne faut pas forcer les acheteurs à créer un compte, seulement leur demander les informations nécessaires. De toute façon, le navigateur les remplit automatiquement. Ensuite, on leur envoie par e-mail un lien pour consulter l’état de la commande, puis on leur redemande leur e-mail à la commande suivante. La friction supplémentaire entraîne une perte de chiffre d’affaires plus importante que le bénéfice d’obtenir des « utilisateurs inscrits ».
  • Je gère une petite app B2C : les utilisateurs s’inscrivent seulement avec leur adresse e-mail, et il n’y a tout simplement pas de champ mot de passe. Le compte est créé et, sur cet appareil, ils restent connectés indéfiniment.
    Ce n’est que lorsqu’ils doivent se connecter depuis un autre appareil qu’ils peuvent demander un nouveau mot de passe. Cela réduit la friction à l’inscription et les mots de passe faibles. La plupart des gens n’ont de toute façon presque jamais besoin de se connecter depuis un autre appareil.
  • J’ai implémenté ce mode de connexion plusieurs fois, et il vient de l’expérience consistant à retirer énormément d’hypothèses sur ce qu’est un « compte utilisateur ». En pratique, ce genre de simplification était nécessaire pour que le funnel fonctionne comme les deux parties le souhaitaient.
    Si l’on n’est pas dans un domaine où l’anonymat doit être préservé, on peut faire comme ça, puis intégrer les passkeys plus tard. L’inconvénient est que le partage de mot de passe devient impossible, donc il faut réfléchir plus tôt à la gestion de plusieurs utilisateurs sur un même compte. Mais si on le traite consciemment, le funnel et l’expérience utilisateur finissent par s’améliorer. La sécurité est aussi liée au niveau moyen de sécurité des fournisseurs d’e-mail des utilisateurs, mais c’est généralement meilleur que le niveau nécessaire. Les mots de passe peuvent servir plus tard de second facteur lorsqu’ils deviennent nécessaires, ou l’on peut ajouter un autre facteur ; en B2B, on peut passer directement à SAML ou OIDC. En B2B comme en D2C, cela a toujours bien fonctionné, et les cas limites valaient la peine d’être résolus au vu du gain d’acquisition.
  • J’ai déjà vu ce mode de connexion : ne pourrait-on pas envoyer dans l’e-mail un lien qui renvoie vers l’accueil de l’app en étant déjà connecté ?
    Copier le code, retrouver l’onglet où la page de connexion est ouverte, puis coller le code, c’est pénible.
  • J’ai utilisé cette approche pour une petite app CRUD qui était presque un simple formulaire, et pendant la campagne, les demandes au support ont été quasiment nulles, donc ça en valait largement la peine.

• À ce stade, pourquoi ne pas envoyer à l’adresse e-mail un lien URL à usage unique permettant de se connecter en un clic ? Il expirerait au bout de 10 minutes et serait invalidé après une utilisation.
  Bien sûr, la première personne à avoir le lien peut se connecter au compte, mais il n’est de toute façon accessible que depuis l’e-mail. Toute notion de sécurité au-delà du compte e-mail disparaît, mais la réalité en est déjà là. Si l’on utilise par SMS un schéma du type « cliquez pour valider la connexion : www.someurl.com?p=134234535 », cela devient une authentification à deux facteurs sans avoir à saisir bêtement un code.

  • Plusieurs webapps utilisent cette approche, mais c’est déroutant pour les utilisateurs (« pourquoi ai-je déjà un compte ? Je ne me suis jamais inscrit ! »), cela coûte de l’argent (l’envoi d’e-mails n’est pas gratuit) et c’est lent.
    L’e-mail peut partir en spam, le greylisting peut empêcher la connexion pendant des heures, ou il peut mettre une minute à arriver, ce qui paraît déjà trop long. Je ne suis pas sûr de la recommander.
  • Je déteste vraiment les sites qui ne proposent que ce mode de connexion et n’arrivent pas à envoyer l’e-mail en moins de 30 secondes.
    Pour le « cliquez pour valider la connexion » envoyé sur mobile, il faut fournir à la fois le code et le lien. L’appareil sur lequel on se connecte n’est pas toujours le téléphone, donc il faut que ce soit « saisissez 1234 ou cliquez ».
  • Certains sites, comme Netdata, font ça.
    Mais c’est plus lent qu’un gestionnaire de mots de passe qui remplit automatiquement le couple nom d’utilisateur/mot de passe, puisqu’il faut attendre l’e-mail puis cliquer sur le lien.
  • Je développe une webapp avec exactement ce parcours de connexion, et j’ai eu un problème sur mobile. Les apps comme Gmail ne permettent pas de copier le lien vers le navigateur sans aperçu, et cet aperçu consomme le lien (next.js auth).
    Je ne veux pas me connecter dans le navigateur intégré de Gmail, je veux me connecter dans mon navigateur habituel, et c’est assez agaçant.
  • À ce compte-là, autant aller jusqu’au bout avec du single sign-on. 95 % des utilisateurs utiliseront de toute façon Gmail, Outlook ou Apple.
    Un bouton « Se connecter avec Google » est préférable à « envoyer un lien par e-mail », et dans les deux cas, le suivi reste possible.

• L’idée qu’une personne crée et mémorise un mot de passe pour chaque petit service sans importance n’est pas réaliste. Construire un énième système d’authentification basé sur des mots de passe relève presque du jeu de rôle
  Les mots de passe sont généralement utilisés de l’une de deux façons : via un gestionnaire de mots de passe protégé par un vrai mot de passe unique, ou comme le même mot de passe répété d’un service à l’autre. Comme presque tous les services proposent une récupération par e-mail, en pratique l’e-mail est le moyen d’authentification. On change rarement son e-mail personnel, on ne le partage pas, et on ne le réutilise pas non plus. Il est même probable qu’on ait utilisé son e-mail personnel plus longtemps que son numéro de téléphone. Pendant que j’utilisais mon adresse e-mail actuelle, mon numéro de téléphone a changé au moins cinq fois, et ces numéros sont désormais utilisés par d’autres personnes

  • Il existe aussi des mots de passe dérivés, une sorte d’hybride. Cela peut être un schéma mémorisé par l’utilisateur, ou un outil de gestion qui les calcule par domaine
    Et la fonction de récupération de mot de passe informe au moins le propriétaire de l’adresse de toutes les tentatives. Une connexion par mot de passe n’envoie pas toujours un e-mail à chaque connexion depuis un nouvel emplacement
  • Apple a rendu bien meilleur le processus où il faut « ne pas simplement saisir le mot de passe 1Password/Keychain, mais être embêté par un e-mail ». Du moins quand il reconnaît un e-mail ou un SMS et remplit le code à votre place

• La réponse est simple. Elle tient généralement aux frictions que le fournisseur de service a créées pour ses utilisateurs. Dans ce cas, cela semble clair : les sessions des fournisseurs d’e-mail ne se terminent généralement presque jamais, et restent connectées tant qu’on ne vide pas le cache du navigateur
  Il suffit de donner au jeton d’authentification de son propre service la même durée de vie que Gmail, et de proposer en alternative une connexion à chaque fois avec un mot de passe à usage unique. Mais il faut arrêter ces pratiques sacrilèges comme les jetons d’authentification de 12 heures. Alors les utilisateurs ne se connecteront plus jamais via la récupération de mot de passe

  • La vraie raison est peut-être simplement que ces sites ne fonctionnent pas correctement
    J’ai déjà eu des problèmes avec des comptes Epic et Spotify. On crée un compte, on l’utilise une semaine, puis la session expire et Spotify vous éjecte du compte. Quand on essaie de se connecter, il dit que le mot de passe est incorrect, ce qui est impossible puisqu’il est enregistré dans le gestionnaire de mots de passe. Au final, on n’a pas d’autre choix que de réinitialiser par e-mail. Les premières fois, même après avoir reçu l’e-mail et réinitialisé, le même schéma se répète ; au bout de 3 ou 4 fois, même l’e-mail n’arrive plus et il faut créer un nouveau compte. Maintenant, j’utilise Spotify en me connectant avec mon compte Google et je n’ai pas encore eu de problème. Mais avec une adresse e-mail classique, leur système d’authentification ne fonctionne tout simplement pas
  • Je pense que c’est un indice plus proche de la vérité. Gmail, Cloudflare et beaucoup d’autres « organisations à haute sécurité » ont des sessions d’authentification très longues. La raison est que la probabilité qu’une personne ait accès au PC de quelqu’un qui utilise ces systèmes, alors que l’utilisateur ne s’est pas déconnecté, est en réalité très faible. La plupart des piratages ciblent à distance des mots de passe faibles
    Le problème, c’est qu’il manque un langage cohérent pour mesurer le risque et décider : « ce site a-t-il vraiment besoin d’une authentification à deux facteurs ? », « une durée de session de 30 minutes est-elle raisonnable ? ». Avec un antivirus à jour, la plupart des gens voudront rester connectés. Vous a-t-on déjà demandé de supprimer tous vos cookies pour corriger un problème sur un site ? Ma réponse est toujours non. On m’a déjà dit : « le compte est à vous, et si vous voulez rester connecté en acceptant le risque de piratage, c’est votre risque, pas celui de l’opérateur du service » ; je suis de plus en plus d’accord. Si quelqu’un supprime toutes vos instances EC2 alors que votre ordinateur portable était connecté, ce n’est pas la faute d’AWS pour ne pas vous avoir déconnecté plus tôt, c’est la vôtre. AWS pourrait le faire, mais pourquoi le devrait-il ? Il n’y a aucune raison d’agacer un million de personnes pour protéger une seule personne négligente
  • C’est juste. J’en ai assez que les plateformes jouent les nounous avec des limites de session et de l’authentification à deux facteurs forcée. Il suffit de mettre un interrupteur dans les paramètres

• J’ai déjà vu des sites qui suppriment l’étape de récupération du mot de passe, voire le mot de passe lui-même. L’e-mail est l’authentification
  On saisit son adresse e-mail, on reçoit un e-mail contenant un code, puis on saisit ce code pour se connecter. Je comprends pourquoi ils font ça, mais quand on utilise plusieurs adresses e-mail, c’est assez pénible. J’ai dû mettre l’e-mail et des notes dans mon gestionnaire de mots de passe pour me souvenir de l’adresse à utiliser, et ça reste comme une entrée sans mot de passe

  • La friction liée aux magic links était telle que j’ai déjà évité de dépenser de l’argent sur ce genre de site et cherché une alternative
    Si un site n’est même pas capable de construire un système de connexion correct, il y a de fortes chances qu’il n’ait pas non plus les compétences pour fournir les fonctionnalités promises. Les magic links ne sont plus seulement une gêne, ils sont devenus un filtre
  • Nous utilisons cette méthode dans du SaaS B2B. Comme chaque utilisateur individuel se connecte au mieux une ou deux fois tous les six mois, une connexion sans mot de passe est avantageuse
    Il n’y a pas la charge de mémoriser un mot de passe pour un service peu utilisé, et l’onboarding en entreprise est plus simple. L’entreprise importe un CSV d’utilisateurs, et ceux-ci peuvent commencer à travailler immédiatement, sans créer ni confirmer de mot de passe ni respecter des règles. Je ne préfère pas les liens par e-mail, car les aperçus des applis mobiles ou les scanners antivirus d’entreprise peuvent « cliquer » sur le lien
  • Une grande partie des consommateurs non techniques n’utiliseront pas de gestionnaire de mots de passe. Si vous ne proposez qu’une inscription par mot de passe, sans magic link ni code, vous rendez la vie plus difficile à la majorité des consommateurs
    Même si vous proposez les deux, demander un mot de passe tout en imposant une vérification par e-mail risque d’augmenter les abandons dans le parcours d’inscription. En plus, ne pas avoir à gérer les mots de passe et plusieurs flux de connexion par e-mail rend aussi le code beaucoup plus simple
  • Un site de « connexion invité » pour échanger des bons proposait cette méthode, et je pense que c’est un cas d’usage valable pour les personnes qui ne veulent pas forcément créer de compte
    Comme le bon devait être associé à une adresse e-mail, il fallait confirmer la possession en cliquant sur un lien, au cas où une perte du bon entraînerait plus tard un problème de support. Si l’on créait ensuite un compte, on pouvait aussi voir les bons reçus précédemment
  • Cela veut dire que le site ne stocke pas mon mot de passe, donc il y a moins de choses à craindre

• Ce n’est qu’après avoir lu cet article que j’ai réalisé que j’utilisais exactement cette méthode chez Best Buy
  Ce n’était pas intentionnel. Mon mot de passe est enregistré dans 1Password, donc je sais qu’il est correct, mais chaque fois que j’essaie d’acheter quelque chose sur bestbuy.com, une sorte de protection contre le piratage de compte se déclenche et prétend à tort que le mot de passe est incorrect. Je veux bien croire que le problème puisse venir de mon côté. Ça pourrait être un bloqueur de pubs ou un blocage DNS local. Mais après quelques répétitions, on perd l’envie de déboguer et on suit simplement le chemin de moindre résistance.

  • Et si c’était une incohérence de longueur maximale ? Il est très courant que le champ de changement de mot de passe et la page de connexion aient des maxlength différents
    Par exemple, si vous saisissez un mot de passe de 60 caractères lors du changement de mot de passe, mais que la longueur maximale sur la page de connexion est de 40 caractères, vous obtiendrez « mot de passe incorrect » à la connexion. C’est pourquoi j’applique désormais une règle qui consiste à stocker la longueur maximale dans la configuration de l’application afin qu’elle soit propagée à tous les champs de mot de passe. Après vérification, il y a bien une incohérence de longueur. Le formulaire de définition du mot de passe a un maxlength de 54, tandis que la page de connexion n’a pas de maxlength. Donc si le mot de passe dépasse 54 caractères et que 1Password ne tronque pas automatiquement le mot de passe enregistré à 54 caractères ou moins, il est impossible de se connecter.

• Pour la plupart des gens, utiliser un ordinateur consiste à réessayer bêtement jusqu’à ce que ça marche à peu près. Les logiciels sont conçus par des personnes qui comprennent en détail les systèmes sous-jacents, mais ils sont faits pour des personnes qui n’ont pas cette compréhension
  Quand les utilisateurs trouvent un schéma qui fonctionne une fois, ils s’y tiennent. Maintenant que beaucoup d’écoles utilisent des tablettes dans l’enseignement, cette tendance s’accentue. Ils n’ont pas vraiment d’intuition sur le fonctionnement d’un ordinateur. La plupart n’y réfléchissent pas en profondeur. C’est juste là, et comme ils sont habitués à ce que ce soit cassé par défaut, quelques clics de plus, ce n’est pas si grave.

  • Parmi les développeurs logiciels, ceux qui comprennent vraiment en profondeur ce qu’ils font représentent probablement autour de 10 %. C’est plutôt parce que les développeurs ne comprennent pas correctement ce qu’ils font que les gens ordinaires arrivent à peine à utiliser des logiciels médiocres en procédant par essais répétés.

• En forçant le trait, les flux de connexion sont identiques
  A) Aller sur le site, copier-coller une chaîne aléatoire via un gestionnaire de mots de passe, puis recevoir par e-mail une demande TOTP pour vérifier son identité. Ou B) aller sur le site, cliquer sur mot de passe oublié, recevoir un lien de connexion, puis saisir une chaîne aléatoire. Dans beaucoup de cas, B est en réalité plus rapide, et presque jamais plus lent. La case « se souvenir de moi » n’a aucun effet.

  • Qui fait du copier-coller depuis un gestionnaire de mots de passe ?
    Je trouve que mon flux est meilleur que les deux. J’arrive sur le site, Safari propose le remplissage automatique, j’utilise TouchID/FaceID, puis on me demande un code de deuxième facteur. S’il arrive par SMS ou par e-mail, Safari propose le remplissage automatique. Même avec du TOTP, Safari le remplit automatiquement. C’est très simple. Les passkeys sont encore plus simples, car il n’y a pas de deuxième étape ni d’attente de SMS/e-mail.
  • Le TOTP n’est pas censé être envoyé par e-mail. Le principe du TOTP est de pouvoir générer directement un code d’authentification à partir de l’heure actuelle et d’un secret prépartagé.
  • Avec du greylisting, le flux B peut prendre une dizaine de minutes.
  • La méthode B fonctionne partout où l’on peut accéder à ses e-mails, et ne dépend pas du fait d’avoir une appli ou son téléphone en main.
  • Le navigateur ne mémorise-t-il pas les mots de passe ?

• La motivation se comprend immédiatement. Si l’on utilise « mot de passe oublié », on n’a pas besoin de se souvenir du mot de passe. Et la sécurité du compte n’est pas davantage affaiblie. Après tout, ce chemin était déjà ouvert aux attaquants
  Certains sites web en font le flux par défaut, affirmant implicitement que si l’on peut envoyer à quelqu’un un bouton de connexion par e-mail, le mot de passe lui-même ne sert à rien. Personnellement, je n’aime pas ça. Je ne fais pas confiance à l’e-mail, et je n’aime pas qu’il devienne le point de défaillance unique de dizaines de comptes. Si l’on peut se connecter avec le seul deuxième facteur, ce n’est pas de l’authentification à deux facteurs. J’aimerais me connecter avec un mot de passe, sans option de réinitialisation, mais la réalité n’est pas ainsi faite.

  • Si l’e-mail est protégé par une authentification à deux facteurs, alors cela redevient de l’authentification à deux facteurs