Une MFA est dite résistante au phishing lorsqu'un attaquant qui intercepte l'intégralité de l'échange ne peut rien en rejouer. Ce critère élimine la majorité des méthodes déployées aujourd'hui : SMS-OTP, code TOTP et notification push transmettent une valeur qu'un attaquant bien placé peut relayer en temps réel.
Le vrai mécanisme d'attaque : l'AiTM, pas le vol de mot de passe
Le phishing moderne ne cherche plus seulement un mot de passe. Il utilise un proxy inverse : la victime consulte une page qui ressemble au service légitime, mais chaque saisie est relayée vers le vrai site, en direct.
Le déroulé est le suivant :
- La victime saisit son identifiant et son mot de passe sur la page relais.
- Le service légitime demande le second facteur. La demande est transmise à la victime.
- La victime fournit son OTP ou approuve la notification — de bonne foi.
- Le service considère l'authentification réussie et émet un cookie de session.
- L'attaquant capture ce cookie et poursuit la session sans avoir besoin d'un seul facteur.
Le point à retenir : la MFA n'a pas échoué techniquement, elle a été traversée. Et comme le butin est la session, changer le mot de passe après coup ne suffit pas — il faut révoquer les jetons.
Ce qui distingue une méthode résistante
Trois propriétés font la différence :
- Liaison à l'origine (origin binding) : la réponse cryptographique est calculée pour un domaine précis. Sur un faux domaine, elle est inexploitable. C'est ce que fait FIDO2/WebAuthn.
- Absence de secret partagé rejouable : rien de transmissible ne circule.
- Preuve d'intention : l'utilisateur valide l'action, pas seulement une connexion.
| Méthode | Rejouable par un relais ? | Résistante au phishing | Faiblesse principale |
|---|---|---|---|
| Mot de passe seul | Oui | Non | fuite, réutilisation |
| SMS-OTP | Oui | Non | relais + SIM swapping ; classé « restricted » par le NIST |
| OTP par e-mail | Oui | Non | compromission de la boîte mail |
| TOTP (app) | Oui | Non | relais en temps réel |
| Notification push | Oui (approbation) | Non | MFA fatigue, approbation réflexe |
| Passkey / FIDO2 | Non | Oui (connexion) | vol de session après authentification |
| Clé physique | Non | Oui (connexion) | logistique, perte, coût |
| Facteur cognitif | Non | Oui, y compris au niveau de l'action | déploiement à prévoir |
La MFA fatigue : l'attaque qui n'a même pas besoin de proxy
Le push bombing consiste à envoyer des dizaines de notifications d'approbation jusqu'à ce que la victime cède — par lassitude, par confusion, ou en pensant régler un bug. La compromission d'Uber en 2022 a rendu ce scénario célèbre : l'attaquant disposait d'identifiants valides, il ne manquait que l'approbation.
Ce cas illustre un point de fond : la friction n'est pas la sécurité. Multiplier les sollicitations crée un automatisme, et l'automatisme est exactement ce que l'attaquant exploite. Un facteur qui demande un raisonnement actif casse cet automatisme, là où un bouton « Approuver » l'entretient.
Le trou restant : la session
Les méthodes liées à l'origine (FIDO2, clés physiques) résolvent le problème de la connexion. Elles ne disent rien de ce qui se passe ensuite : un jeton volé (via malware, extension, ou vol de cookie) permet d'agir sans repasser par l'authentification.
D'où deux réponses complémentaires :
- Authentification transactionnelle : au lieu d'authentifier une session puis de faire confiance, on demande une validation explicite au moment de l'opération sensible (virement, changement d'IBAN, création de compte à privilèges).
- Exécution mouvante (Moving Target Defense) : les paramètres varient en continu, ce qui rend l'interception stable et le rejeu inopérants.
C'est précisément l'angle du facteur cognitif : un challenge résolu au moment de l'action, sans secret réutilisable, dans un canal éphémère.
Plan d'action réaliste
- Cartographier les méthodes en place, parcours par parcours. La question utile n'est pas « avons-nous la MFA ? » mais « laquelle, et sur quelles actions ? ».
- Éliminer le SMS-OTP sur les parcours sensibles en priorité.
- Basculer les administrateurs vers une méthode liée à l'origine — c'est la population la plus ciblée.
- Réduire la durée de vie des sessions sur les périmètres critiques et savoir révoquer les jetons.
- Ajouter une validation d'intention sur les opérations à fort impact financier ou juridique.
- Traiter la population : la sensibilisation seule ne suffit pas, mais un utilisateur qui sait qu'on ne lui demandera jamais d'approuver une notification qu'il n'a pas déclenchée devient un capteur.
FAQ
Le TOTP est-il vraiment vulnérable au phishing ?
Oui. Le code est valide quelques dizaines de secondes, ce qui suffit largement à un proxy inverse automatisé pour le relayer. Le TOTP protège contre la réutilisation d'un mot de passe volé, pas contre un relais en temps réel.
Les passkeys suffisent-elles alors ?
Elles constituent un progrès majeur sur la connexion grâce à la liaison à l'origine. Restent deux angles morts : le vol de session après authentification, et les parcours de récupération de compte, souvent retombés sur un e-mail ou un SMS.
Comment détecter une attaque AiTM ?
Signaux utiles : incohérences entre l'adresse IP/agent de l'authentification et de l'usage, géovélocité anormale, sessions actives depuis des infrastructures d'hébergement, et surtout authentifications réussies suivies immédiatement de changements de paramètres sensibles.
Faut-il supprimer la notification push ?
Pas nécessairement, mais il faut l'assortir de contre-mesures : correspondance de numéro (number matching), contexte affiché, limitation du nombre de demandes, et surtout ne pas s'en servir seule pour valider une opération sensible.
Aller plus loin : pilier : authentification cognitive · MFA fatigue et push bombing · AiTM expliqué · choisir une solution