Passkeys et relais de phishing : pourquoi la liaison à l'origine bat les codes à usage unique
Les kits de phishing qui s'interposent entre l'utilisateur et la vraie page de connexion sont devenus l'un des moyens les plus fiables de vaincre l'authentification multifacteur. La victime tape un code à usage unique, le kit le relaie au vrai site en quelques secondes, et l'attaquant garde la session qui revient. Une passkey brise ce relais comme aucune méthode à base de codes : il n'y a tout simplement rien à copier à l'écran.
Comment les kits AiTM engloutissent les codes à usage unique
Microsoft a documenté la mécanique en détail : l'éditeur a suivi une campagne qui a touché plus de 10 000 organisations à partir de septembre 2021. L'attaquant fait tourner un proxy inverse qui sert une copie pixel par pixel de la vraie page de connexion sur son propre domaine, en maintenant deux sessions TLS : une avec la victime, l'autre avec le vrai site. Mots de passe et cookies de session transitent par le milieu, et l'attaquant se connecte à la place de l'utilisateur. Microsoft a souligné qu'il ne s'agit pas d'une vulnérabilité du MFA ; le code est authentique, la connexion est authentique, et le kit garde simplement ce que l'utilisateur remet (Microsoft). La technique n'a pas disparu. En janvier 2026, des chercheurs de Microsoft décrivaient une campagne AiTM multi-étapes visant des organisations du secteur de l'énergie, arrivée par des liens SharePoint détournés et finie en fraude financière (Microsoft). Une année de télémétrie Kaspersky publiée en août 2026 recense plus de 390 000 pages de phishing sur des plateformes cloud légitimes, beaucoup utilisant des bibliothèques proxy open source et des fenêtres browser-in-the-browser qui falsifient la barre d'adresse (Kaspersky). Le kit moderne relaie le code, l'approbation push et le cookie qui en résulte en temps réel. Tout, sauf l'URL, est réel.Liaison à l'origine : le domaine fait partie de la credential
WebAuthn, la norme derrière les passkeys, fonctionne autrement. À l'enregistrement, le site et le navigateur créent une paire de clés publique et privée cantonnée à un identifiant de partie dépendante (relying party ID), en pratique le domaine du site. La clé privée ne quitte jamais l'appareil, et le navigateur ne propose une credential que si l'origine de la page correspond à cet identifiant. La documentation de Mozilla le dit sans détour : un attaquant qui fabrique un faux site de connexion ne peut pas se connecter à la place de l'utilisateur, car la signature change selon l'origine du site (Mozilla). La FIDO Alliance décrit les passkeys comme uniques par site ou application - c'est précisément ce qui prive le credential stuffing de matière (FIDO Alliance). Cisco Talos a montré ce que cela implique pour les kits proxy : une victime qui atterrit sur un faux domaine imitant sa banque ne peut pas mener la cérémonie WebAuthn à son terme, car le navigateur n'offre pas de credential liée au vrai domaine sur le faux. L'authentification échoue avant que le moindre secret ne transite (Cisco Talos).Un kit proxy peut tout relayer, tout ce que l'utilisateur tape. Il ne peut pas relayer une credential que le navigateur ne propose jamais.Même quand la cérémonie a lieu, rien de réutilisable ne passe sur le fil. Le serveur envoie un challenge aléatoire de grande taille, l'authentificateur le signe avec la clé privée, et la signature prouve la possession sans révéler aucun secret, comme le note la spécification de Mozilla. Un proxy peut retransmettre cette signature, mais le vrai site verrait alors une réponse revendiquant une origine qu'il n'a jamais servie, avec une credential dont il vérifie l'identifiant de partie dépendante précisément pour ce cas. Pas de code qui court contre un chronomètre de trente secondes, pas de cookie frappé du côté de l'attaquant.