- Les magic links, qui envoient un lien de connexion par e-mail, peuvent réduire les risques de phishing de mots de passe et de compromission liée à la réutilisation de mots de passe, mais s’ils deviennent l’unique option, ils reportent la friction de connexion sur l’utilisateur
- Les personnes qui utilisent plusieurs ordinateurs ou séparent appareils professionnels et personnels se retrouvent souvent avec un flux qui se casse facilement, car l’appareil qui reçoit l’e-mail n’est pas celui du navigateur où elles veulent se connecter
- À cause des délais SMTP et du transfert du lien, la connexion peut prendre de 2 secondes à plusieurs minutes, et dans les navigateurs intégrés aux apps ou les lecteurs RSS, l’expérience mobile peut aussi se dégrader
- Saisir directement un OTP reçu par e-mail ou SMS est également contraignant, mais cela peut être préférable à un magic link lorsqu’il est difficile de transférer le lien entre le client e-mail et le navigateur
- Même si les magic links restent l’option par défaut, il faut aussi proposer aux utilisateurs techniques et soucieux de leur vie privée des alternatives solides comme les passkeys
Quand les magic links deviennent pénibles
- « Magic Links » désignait autrefois un PDA futuriste, mais aujourd’hui le terme est utilisé par des entreprises comme Auth0 pour parler de liens de connexion inclus dans des e-mails
- Dans “We Don’t Want Your Password”, 404 Media défend les magic links en estimant que les liens reçus par e-mail sont plus difficiles à phisher qu’un mot de passe, n’entraînent pas de fuite de mot de passe et réduisent aussi le risque de réutilisation de mots de passe compromis
- Cela peut sembler simple dans une vie centrée sur un seul ordinateur portable et un mobile, mais pour les utilisateurs qui emploient plusieurs appareils et navigateurs, la complexité leur est simplement transférée
- Exemples de situations pénibles :
- Plusieurs appareils : les personnes qui ne mettent pas leur e-mail personnel sur leur PC de jeu ou leur ordinateur portable professionnel ont du mal à ouvrir immédiatement le lien de connexion
- Vitesse : à cause du délai SMTP et du passage du lien vers le bon navigateur, cela peut prendre de 2 secondes à plusieurs minutes
- Mobile : l’usage des navigateurs intégrés aux apps se dégrade, ce qui rend la gestion des liens locaux peu pratique dans les lecteurs RSS
- Sécurité : des flux qui poussent à ouvrir son e-mail personnel sur un appareil pro, ou l’inverse, ne constituent pas un avantage en matière de sécurité
Alternatives et améliorations minimales
- La connexion sans mot de passe par saisie directe d’un OTP reçu par e-mail ou SMS reste peu confortable, mais peut être plus pratique lorsqu’il n’est pas facile de transférer un lien depuis le client e-mail vers le navigateur où l’on veut se connecter
- Stratechery propose, via Passport, soit un clic sur le lien, soit la saisie d’un OTP ; même si cela reste limité faute d’implémentation de passkeys et continue de reporter une partie de l’inconfort sur l’utilisateur, cela tient mieux compte des situations réelles qu’un magic link seul
- Même si l’on insiste pour garder les magic/tragic links comme option par défaut, il vaut mieux proposer aussi des alternatives solides comme les passkeys
- Magic Links Have Rough Edges, but Passkeys Can Smooth Them Over de Ricky Mondello est un article de référence qui explique comment les passkeys peuvent atténuer ce problème
1 commentaires
Avis sur Hacker News
Problèmes rencontrés en développant des apps avec des liens magiques : comme l’utilisateur peut devoir se connecter depuis un appareil où l’accès à l’e-mail est peu pratique, il faut inclure un code de connexion alternatif dans le lien magique.
Il faut aussi gérer les cas où le client e-mail ouvre automatiquement le lien pour générer une capture d’aperçu, et tenir compte des clients e-mail qui ouvrent le lien dans un navigateur intégré plutôt que dans le navigateur préféré de l’utilisateur.
Par exemple, même si un utilisateur iOS préfère Firefox mobile, son app e-mail peut forcer l’ouverture dans un navigateur intégré basé sur Safari.
À mon avis, une approche qui mène à une page de saisie d’un code à usage unique permettrait d’éviter une grande partie de ces problèmes.
J’ai récemment eu un problème où un nouveau compte e-mail était automatiquement vérifié, puis, lorsque l’utilisateur cliquait, le lien magique était déjà invalide, parce que Microsoft s’était connecté en premier via ce lien pendant son analyse.
Après que McDonald's est passé de l’e-mail/mot de passe aux liens magiques, il est devenu vraiment difficile de faire fonctionner le lien dans l’app McD, et la plupart du temps seul le site web de McD s’ouvrait.
Comme, environ 98 % du temps, si je ne peux pas commander via l’app je ne mange pas chez McD, c’était assez agaçant, et j’ai fini par passer à “Sign in With Apple” (SIWA).
Comme je n’ai pas trouvé comment ajouter SIWA à mon compte McD existant, j’ai dû utiliser SIWA en masquant ma véritable adresse e-mail à McD ; cela a créé un nouveau compte, j’ai perdu les points de fidélité de l’ancien, mais au moins je peux de nouveau utiliser l’app McD.
Dans l’app, il y a chaque vendredi une offre “Free Medium Fries on Friday” pour toute commande d’au moins 1 dollar ; donc, chaque vendredi midi, je me fais souvent un sandwich à la maison, puis je prends chez McD un cookie et des frites gratuites pour accompagner.
J’ai donc reçu le lien magique sur mon ordinateur professionnel et généré un QR code, mais le système de quarantaine des e-mails avait réécrit tout le lien, il a donc fallu extraire l’original.
Et ce n’était pas fini : l’URL de redirection vers Slack était cassée à cause de l’encodage URL, j’ai donc dû la corriger à la main avant de générer le QR code.
Il suffirait simplement de mettre un QR code ou un code dans l’e-mail du lien magique d’origine.
Dès qu’on ajoute un code à saisir, cet avantage disparaît complètement : un attaquant n’a plus qu’à créer un faux site web demandant ce code.
Un lien magique doit connecter l’utilisateur sur l’appareil où il est cliqué, pas sur l’appareil qui a demandé la session de connexion.
Toute autre approche est peut-être un peu moins pénible, mais c’est un problème de sécurité, et il faut la traiter comme telle.
J’utilise les liens magiques depuis plusieurs années, en partie parce qu’au stade MVP je voulais éviter la charge de sécurité liée au stockage des mots de passe utilisateur. Le plus gros problème, c’est qu’environ 0,1 % des utilisateurs ne reçoivent tout simplement jamais les e-mails.
J’ai essayé une IP dédiée, MailGun, PostMark, et même des tentatives successives via plusieurs outils d’e-mail transactionnel, mais il reste toujours des personnes qui ne peuvent absolument pas se connecter.
Autre point : des gens cliquent sur un lien magique vieux de six mois et s’énervent en disant que “ça ne marche pas”, donc au lieu d’un message d’erreur, on a décidé d’afficher une page qui explique la situation et renvoie le lien, à la manière de Docusign.
Il arrive aussi que des gens saisissent souvent mal leur adresse e-mail, puis accusent le système quand ils ne reçoivent pas le code.
Malgré tout, j’ai l’impression qu’il y a beaucoup moins de tickets de support qu’avec le couple e-mail + mot de passe, donc je préfère toujours les liens magiques.
Je n’ai jamais utilisé de liens magiques, mais il y a quelques mois j’ai ajouté Google Sign in à un SaaS, et cela représente désormais plus de 90 % des nouvelles inscriptions.
C’est le cas alors même que la base d’utilisateurs est composée de développeurs, donc plutôt à l’aise techniquement et sensible à la confidentialité ; je ne pense plus qu’une autre méthode soit prioritaire. Bien sûr, l’e-mail/mot de passe reste disponible.
Un couple nom d’utilisateur + mot de passe utilisé avec un gestionnaire de mots de passe, ou des passkeys, est probablement l’un des seuls moyens d’échanger des identifiants de bout en bout chiffrés via HTTPS tout en offrant une bonne expérience utilisateur au grand public.
Le gestionnaire de mots de passe garantit que les identifiants ne sont utilisés que sur le bon domaine.
J’étais un client fidèle de Mercury, mais même après avoir passé un mot de passe sûr, un gestionnaire de mots de passe et un TOTP valide, le fait qu’ils imposent un lien magique comme troisième facteur d’authentification à chaque changement d’adresse IP m’a poussé à envisager de transférer le compte bancaire de l’entreprise ailleurs.
Je comprendrais si je me connectais depuis un endroit ou un FAI que je n’ai pas utilisé depuis cinq ans, mais si la seule différence par rapport à ma connexion d’hier est le dernier octet de l’adresse DHCP, ça n’a aucun sens.
Comme je lis mes e-mails via SSH depuis un autre ordinateur que celui où je navigue sur le Web, copier-coller un lien de connexion de plusieurs centaines de caractères est une vraie plaie.
Dans Emacs, il s’affiche sur plusieurs lignes, et je dois même supprimer à la main les
\en fin de ligne.Ajouter de la friction à chaque connexion dégrade l’impression laissée par toutes les interactions qui suivent dans l’application, et donne envie de ne plus l’utiliser.
S’il s’agit d’un appareil déjà utilisé, la vérification de l’appareil ne devrait pas être demandée. Nous stockons un cookie persistant pour le vérifier, et nous ne la demandons pas non plus depuis la même IP. Je me demande si vos cookies ne sont pas supprimés régulièrement.
Nous avons ajouté cette fonctionnalité après que des attaquants ont créé des sites clones de http://mercury.com et même diffusé des publicités Google.
Quand un client saisissait son mot de passe et son TOTP sur un site de phishing, le fraudeur utilisait ces identifiants pour se connecter, créer des cartes virtuelles et acheter des cryptomonnaies, de l’or, etc., puis redirigeait l’utilisateur vers le vrai Mercury en espérant qu’il y voie une erreur temporaire.
Le lien de vérification d’appareil que nous envoyons approuve l’IP/l’appareil depuis lequel le lien est ouvert, et cette méthode a presque entièrement bloqué les fraudeurs.
WebAuthn étant immunisé contre ce type d’attaque de phishing, nous ne demandons pas de vérification d’appareil lorsque WebAuthn est utilisé.
Si vous le pouvez, je recommande fortement TouchID/FaceID ou WebAuthn propre à l’appareil. C’est plus pratique et plus sûr, et vous pouvez l’ajouter ici : https://app.mercury.com/settings/security
Cela dit, nous discutons de cet article en interne, et nous sommes aussi conscients qu’avec la généralisation d’IPv6, les IP changeront beaucoup plus souvent. Nous allons réfléchir à un éventuel assouplissement de la contrainte de correspondance avec la même IP.
Je trouve que c’est une très bonne réaction à l’article 404 de la semaine dernière. J’aime 404, mais pour les mêmes raisons que celles citées par l’auteur, les liens magiques m’agacent.
L’article que Ricky Mondello a écrit la semaine dernière[1] explique bien que les passkeys peuvent être utilisés avec les liens magiques, comme le suggère la fin de l’article, et il vaut la peine d’être lu.
[1]: https://rmondello.com/2025/01/02/magic-links-and-passkeys/
Quand on essayait de se connecter au store, il fallait saisir le code en deux étapes envoyé par e-mail ; le mail n’arrivait pas pendant plusieurs minutes, on demandait un nouveau code, il n’arrivait toujours pas, puis on abandonnait pour faire autre chose, et 30 minutes plus tard les deux codes arrivaient en même temps.
En réalité, même dans le meilleur des cas, l’e-mail est difficile à considérer comme fiable. Il peut finir dans les spams, un filtre antispam d’entreprise peut bloquer les liens, ou la boîte de réception peut être pleine.
Personnellement, je n’ai mes e-mails que sur mon iPhone ; sur mon portable de travail ou mon PC de jeu, je dois me connecter à icloud.com pour les consulter, ce qui est pénible.
J’aimerais qu’on me laisse saisir un mot de passe, scanner un QR code comme sur les appareils embarqués, ou qu’on me donne au moins une autre option.
Les liens magiques permettent d’accéder aux passkeys, et les passkeys sont en gros une version renforcée de « se souvenir de cet ordinateur ».
Je suis encore habitué à l’époque où les gens d’Apple étaient presque invisibles publiquement.
Je ne sais pas si j’ai mal compris quelque chose, mais les passkeys ne me semblent pas être réellement une alternative aux magic links.
Toutes les implémentations de passkeys que j’ai vues jusqu’ici proposaient de créer une passkey après s’être déjà connecté par un autre moyen.
Je n’ai pas creusé en profondeur, mais du point de vue de l’expérience utilisateur, les passkeys ressemblent davantage à une alternative au bouton « se souvenir de cet ordinateur » qu’à une alternative aux mots de passe en général.
D’une manière ou d’une autre, le service doit savoir que ce nouvel appareil a été approuvé.
Selon le fournisseur, il existe bien une synchronisation des passkeys, mais cela ne résout pas la question de l’authentification initiale.
L’idée essentielle des magic links, c’est qu’un système de sécurité ne peut pas être plus fort que son mécanisme de récupération.
Il n’y aura pas de monde où les passkeys seraient traitées comme l’unique moyen d’authentification ; il restera toujours un mécanisme de récupération, et dans la plupart des cas ce sera une récupération automatique par e-mail.
Dans ce cas, les magic links ont l’honnêteté de simplifier les choses sans faire semblant qu’il existe une couche plus sûre par-dessus.
Faire du mécanisme de récupération le principal moyen d’interaction du flux d’authentification revient à être plus honnête sur le niveau de sécurité réel du système d’authentification.
Édition : filmgirlcw a laissé un lien vers un meilleur article expliquant comment les deux approches se complètent réellement : https://news.ycombinator.com/item?id=42628226
Les magic links ont aussi des avantages, mais je ne suis pas sûr que faire de l’e-mail un vecteur d’attaque plus puissant en soit un.
Pour les personnes qui utilisent un gestionnaire de mots de passe, les magic links sont clairement un point de friction, et les passkeys peuvent nettement le réduire.
L’expérience utilisateur des passkeys peut encore être améliorée, et lorsque l’export deviendra possible, la synchronisation entre systèmes sera bien meilleure.
L’une des raisons pour lesquelles j’utilise 1Password comme système principal pour les mots de passe et les passkeys est justement l’usage des passkeys entre appareils ; mon entreprise utilise aussi 1Password, ce qui me permet d’être connecté à mes comptes personnels et professionnels et de m’authentifier depuis un appareil personnel ou de travail si nécessaire.
Cela dit, si le problème tel que 404 le définit est de ne pas vouloir assumer la responsabilité du stockage des mots de passe ou des contrôles d’authentification, alors je pense que les passkeys sont meilleures que les magic links pour certains utilisateurs.
Mais comme Ricky, je pense qu’il ne faut pas choisir l’un ou l’autre : il faut les deux.
[1]: https://rmondello.com/2025/01/02/magic-links-and-passkeys/
Utiliser des passkeys ne signifie pas nécessairement qu’il faille une méthode de connexion de secours, mais aucun service n’est encore passé au tout-passkey.
Les utilisateurs d’anciens OS ou de Linux peuvent encore ne pas pouvoir créer et stocker des passkeys, et beaucoup d’utilisateurs n’emploient pas de gestionnaire d’identifiants multiplateforme.
Par exemple, si vous avez créé une passkey avec iCloud Passwords, il n’existe pour l’instant aucun moyen de vous connecter depuis Linux.
D’ici quelques années, je pense qu’on commencera à voir des parcours où les services font créer une passkey dès le départ et ne collectent tout simplement aucun mot de passe.
J’espère que la spécification de portabilité des passkeys sera implémentée, et que Gnome/KDE implémenteront aussi la prise en charge des passkeys.
Si utiliser l’OTP de son téléphone ou copier un lien depuis son téléphone quand on visite un site web depuis un PC professionnel est pénible, je me demande en quoi faire fonctionner un ordinateur de travail avec une passkey personnelle stockée sur un laptop ou ailleurs serait tellement plus simple et meilleur.
Je n’utilise pas les services qui ne prennent en charge que les magic links pour l’authentification. C’est très hostile à l’utilisateur et, du point de vue de la sécurité, c’est clairement pire qu’un mot de passe utilisé avec un gestionnaire de mots de passe.
Le plus rédhibitoire, c’est que dans ma configuration personnelle, cela ne fonctionne tout simplement pas.
Pour des raisons de sécurité et de protection de mes comptes, je n’accède pas à mon compte e-mail depuis les appareils que j’utilise pour me connecter.
Je fais une exception uniquement pour Anthropic, parce que Claude est le meilleur LLM, mais c’est une énorme souffrance à chaque fois que je dois me reconnecter, et j’ai envoyé plusieurs réclamations.
Chaque fois que je vois des magic links, je me dis toujours : « n’était-on pas censés ne pas cliquer sur les liens dans les e-mails, à la base ? »
Quand je pense aux liens dans les e-mails, je pense aussi au phishing.
Je déteste vraiment les magic links.
Le point essentiel, c’est de ne pas cliquer sur des liens suspects. Si vous savez qu’un magic link a été envoyé, ce n’est pas un lien suspect.
Cela dit, je n’aime pas les magic links à cause du délai.
La méthode d’Apple pour la protection de la confidentialité des e-mails a l’air intéressante : Apple charge toujours toutes les images. Je ne sais pas si cela a des inconvénients.
La meilleure implémentation que j’aie vue impose de cliquer sur le lien depuis l’appareil qui a reçu l’e-mail, mais sans transférer la session vers cet appareil : la connexion se termine sur l’appareil qui a lancé la procédure de connexion
Une meilleure solution consiste à n’autoriser la connexion que sur l’appareil où le lien a été ouvert, et, pour l’usage entre appareils, à fournir aussi un code OTP lisible sur l’appareil récepteur et facile à saisir sur l’appareil d’origine.
Ou bien on peut même fournir uniquement un code OTP, sans lien.
Quand on travaille dans un navigateur et qu’on ouvre ses e-mails, il n’y a rien de pire que d’être authentifié dans le navigateur par défaut, ou pire, sur un autre appareil, ce qui oblige à s’y envoyer le lien puis à le rouvrir.
Il peut aussi arriver qu’on ne veuille pas accéder à certains e-mails sur un appareil donné, ce n’est donc pas un scénario si étrange.
Le fait qu’un site envoie un OTP du type
crazy-pink-horse-3837pour qu’on puisse le copier-coller constitue un compromis acceptable si l’implémentation d’un lien qui authentifie la requête initiale est trop difficile.Le problème de l’implémentation, c’est que le magic link envoyé était enveloppé dans un tracker de clics, et que ce domaine était bloqué par des outils comme pihole.
Du coup, il était impossible d’atteindre la véritable URL d’authentification et de terminer la procédure de connexion.
Les navigateurs intégrés aux apps devraient disparaître. Surtout ceux qui ne permettent pas de choisir « ouvrir dans le navigateur normal », et un lecteur RSS devrait évidemment proposer cette option.
Tous les chefs de produit qui imposent un navigateur intégré aux utilisateurs devraient aller en prison.
Une bien meilleure option consiste à utiliser un code OTP envoyé par e-mail et des passkeys avec l’interface Conditional Mediation.
Si l’utilisateur se connecte depuis un appareil qui possède déjà une passkey, l’interface CM peut la proposer immédiatement et permettre une connexion instantanée.
S’il s’agit d’un appareil sans passkey, on peut concevoir une expérience où l’utilisateur saisit le code reçu par e-mail puis, en cas de succès, configure immédiatement une passkey pour pouvoir se connecter directement les fois suivantes.
On obtient ainsi la sécurité des passkeys sur les appareils existants, et une configuration sans mot de passe avec récupération de compte sur les nouveaux appareils.
En bonus, cela évite aussi le verrouillage fournisseur où le fournisseur cloud détient toutes les passkeys.