Pourquoi l'MFA classique perd encore face aux attaques adversary-in-the-middle

L'authentification multifacteur (MFA) reste l'un des meilleurs progrès par rapport au seul mot de passe. Elle bloque la plupart du stuffing automatisé et beaucoup de pages de phishing simples qui ne collectent qu'un mot de passe. Mais elle n'est pas à l'épreuve du phishing. En avril 2026, le National Cyber Security Centre (NCSC) britannique a comparé l'MFA traditionnelle aux identifiants FIDO2 et aux passkeys pour un usage personnel, et a mis en évidence un écart clair : le phishing adversary-in-the-middle (AitM) bat encore le mot de passe associé à SMS, TOTP, notifications push ou codes e-mail, alors que FIDO2 résiste.

Cet article explique cet écart en termes pratiques, et pourquoi passer les comptes à forte valeur vers les passkeys compte davantage qu'ajouter un nouveau code SMS.

L'MFA a freiné le stuffing — pas les proxies de phishing

Le credential stuffing fonctionne parce que les gens réutilisent leurs mots de passe. Une fois qu'un mot de passe fuit d'une violation, les attaquants le testent sur la messagerie, les banques, les sites marchands et le cloud. Un second facteur casse ce schéma : le mot de passe volé ne suffit plus.

Ce succès a créé un modèle mental trompeur. Beaucoup ont entendu que l'MFA « arrête le phishing ». Contre une fausse page statique qui ne capture qu'un mot de passe, l'MFA aide souvent. Contre un proxy de phishing en direct placé entre vous et le vrai site, l'MFA traditionnelle échoue en général. Les rapports industriels citent souvent l'MFA comme bloquant la grande majorité des tentatives automatisées de prise de compte ; ce chiffre décrit le stuffing et le vol peu sophistiqué, pas le vol de session AitM.

Comment fonctionne le phishing adversary-in-the-middle

Dans une attaque AitM, la victime arrive sur un site d'apparence légitime contrôlé par l'attaquant. Ce n'est pas un simple formulaire. C'est un reverse proxy qui relaie chaque requête vers le vrai service en temps réel.

Vous saisissez identifiant et mot de passe. Le proxy les envoie au vrai site. Le vrai site demande un second facteur. Vous tapez le code SMS, le code d'authenticator, l'OTP e-mail, ou vous approuvez une notification push. Le proxy relaie cela aussi. Une fois que le vrai site émet un cookie ou un jeton de session, l'attaquant le copie et reprend la session authentifiée — souvent sans avoir besoin du mot de passe ensuite.

• L'attaquant n'a pas besoin de « casser » la cryptographie MFA. Il attend que vous terminiez une connexion valide.
• L'artefact volé est en général le cookie de session ou le jeton bearer, pas seulement le mot de passe.
• Des outils de type Evilginx ont rendu cette technique largement accessible aux cybercriminels.

Pourquoi SMS, TOTP, push et OTP e-mail échouent tous face à l'AitM

Ces seconds facteurs prouvent qu'une personne capable de recevoir un message, de lire un code rotatif ou d'appuyer sur « Approuver » est intervenue. Ils ne prouvent pas que le navigateur qui parle au vrai site est le vôtre.

• OTP SMS : le code est un secret partagé de courte durée. Si vous le tapez sur une page proxifiée, l'attaquant obtient une connexion valide.
• TOTP d'authenticator : même problème. Le code à six chiffres est valide à la fois pour le vrai site et pour le proxy pendant une courte fenêtre.
• Notifications push : approuver « Était-ce vous ? » valide la connexion de l'attaquant, sauf si l'invite impose une correspondance de numéro claire et que vous vérifiez soigneusement la source.
• OTP e-mail : un autre code relayable. Si l'attaquant a déjà le mot de passe et peut forcer la seconde étape, la livraison par e-mail ne lie pas la connexion à l'origine réelle.

Attaques par fatigue et SIM-swap : autres faiblesses de l'MFA traditionnelle

L'AitM n'est pas le seul échec de l'MFA traditionnelle. Les attaques par fatigue saturent les notifications push jusqu'à ce que quelqu'un accepte pour faire cesser le bruit. Le SIM-swap et l'interception SMS volent les codes avant qu'ils ne vous parviennent.

La comparaison du NCSC traite ces scénarios comme des raisons supplémentaires pour lesquelles l'MFA traditionnelle est plus faible que FIDO2 sur tout le cycle de vie des identifiants. Même sans jamais cliquer sur un lien de phishing, la fatigue push et l'abus SIM restent des menaces personnelles réalistes.

• La fatigue push réussit parce qu'« Approuver » est facile et que l'invite manque souvent de contexte clair.
• Le SIM-swap vise le numéro qui reçoit les codes SMS, pas le mot de passe lui-même.
• Ces échecs confirment la même leçon que l'AitM : un facteur que l'on peut contraindre, relayer ou détourner n'est pas résistant au phishing.

Pourquoi FIDO2 et les passkeys résistent à l'AitM

Les identifiants FIDO2 / WebAuthn — y compris les passkeys — sont liés à l'origine réelle du site. Votre authenticator ne terminera pas une cérémonie pour evil-bank.example si l'identifiant appartient à bank.example.

La clé privée ne quitte jamais l'authenticator (ou le sync fabric protégé pour les passkeys synchronisées). Le site reçoit une signature sur un challenge qui inclut l'origine, pas un secret réutilisable que l'on peut saisir dans un proxy.

C'est pourquoi le tableau du NCSC marque le phishing adversary-in-the-middle comme toujours efficace contre l'MFA traditionnelle et jamais efficace contre les identifiants FIDO2 dans le modèle de menace personnel qu'ils ont évalué.

• La liaison à l'origine empêche l'usage de l'identifiant sur des domaines d'apparence similaire.
• Il n'existe pas de court OTP que l'attaquant puisse relayer en temps réel.
• Le vol de session via une 2SV proxifiée n'emprunte plus le même chemin d'attaque.

Le piège de la transition : déclassement MFA tant que le mot de passe reste une option

Même lorsqu'un service prend en charge les passkeys, beaucoup de comptes conservent un mot de passe plus une MFA plus faible en secours. Les attaquants le savent. Les attaques de déclassement MFA orientent la victime vers le chemin le plus faible : réinitialisation du mot de passe, « se connecter autrement », SMS au lieu de clé de sécurité, ou flux de récupération qui ne présente jamais l'invite passkey.

Pendant la longue coexistence des mots de passe et des passkeys, le chemin le plus faible autorisé décide souvent du vrai niveau de sécurité. Enregistrer une passkey n'aide que si vous résistez aussi à l'UX de déclassement et traitez les options de récupération avec autant de soin que la connexion principale.

Que faire maintenant

Vous n'avez pas besoin d'attendre que chaque site abandonne les mots de passe. Priorisez les comptes qui ouvrent tout le reste, puis renforcez les autres.

• Préférez passkeys ou clés de sécurité pour la messagerie, le gestionnaire de mots de passe, la banque, le cloud et les comptes développeur. Commencez par notre guide passkeys.
• Là où la MFA push reste en place, utilisez la correspondance de numéro et traitez les invites inattendues comme hostiles.
• Évitez le SMS comme second facteur principal lorsqu'une meilleure option existe.
• Tant qu'un compte ne prend pas en charge les passkeys, utilisez un long mot de passe unique via un gestionnaire — le stuffing prospère encore grâce à la réutilisation.
• Passez en revue les options de récupération pour qu'« oubli du mot de passe » ou « essayer une autre méthode » ne puissent pas effacer silencieusement la résistance au phishing.