Face à une attaque adversary-in-the-middle (AiTM), la notification push n'apporte aucune protection supplémentaire par rapport à un code saisi. L'attaquant place un proxy inverse entre la victime et le service légitime : il déclenche lui-même l'authentification, la victime reçoit une demande d'approbation authentique, l'approuve de bonne foi, et le cookie de session émis par le service part chez l'attaquant.
Ce que le push protège réellement
Il faut lui reconnaître ce qu'il fait bien. Un mot de passe seul, obtenu par fuite de base, réutilisation ou pulvérisation de mots de passe, ne permet plus d'ouvrir une session : il manque l'approbation. Contre le bourrage d'identifiants automatisé, le push est efficace, parce que l'attaque repose sur le volume et n'a personne pour approuver.
Il offre aussi un signal opérationnel utile : une demande d'approbation non sollicitée prouve qu'un identifiant valide circule. Correctement remontée, c'est une alerte de compromission, pas seulement une gêne pour l'utilisateur.
Pourquoi l'AiTM traverse cette protection
Le mécanisme mérite d'être décomposé, parce qu'il est souvent mal compris.
- La victime arrive sur une page relais, généralement via un lien ciblé. Cette page n'est pas une copie statique : c'est un proxy qui transmet chaque saisie au service réel.
- Le service réel reçoit un identifiant et un mot de passe valides, et déclenche le second facteur.
- La notification push part vers le téléphone de la victime. Elle est légitime : elle vient du vrai service, avec le vrai libellé.
- La victime approuve, puisqu'elle vient effectivement de tenter de se connecter.
- Le service considère l'authentification réussie et émet un cookie de session, qui transite par le proxy. L'attaquant le capture et poursuit la session.
Le point décisif : la MFA n'a pas été contournée techniquement, elle a été traversée. La victime a réellement authentifié une connexion — celle de l'attaquant.
Le number matching ne règle pas ce problème
C'est l'erreur d'analyse la plus fréquente. La correspondance de numéro (number matching) affiche un code à l'écran de connexion, que l'utilisateur doit recopier dans l'application mobile. Contre un bombardement de notifications, la mesure est très efficace : l'utilisateur ne peut plus approuver au hasard puisqu'il n'a pas le nombre.
Contre un AiTM, elle ne change rien. Le proxy affiche à la victime la page relayée, donc le nombre légitime généré par le vrai service. La victime le lit et le saisit. Le contrôle est satisfait, l'attaque se poursuit.
| Menace | Push simple | Push + number matching | Facteur lié à l'origine |
|---|---|---|---|
| Mot de passe volé utilisé seul | Bloque | Bloque | Bloque |
| Bourrage d'identifiants | Bloque | Bloque | Bloque |
| Bombardement de notifications | Laisse passer | Bloque largement | Sans objet |
| AiTM par proxy inverse | Laisse passer | Laisse passer | Bloque |
| Réutilisation d'un cookie volé | Laisse passer | Laisse passer | Laisse passer |
La dernière ligne mérite attention : aucune méthode de connexion, y compris FIDO2, ne protège un jeton déjà émis. C'est un problème distinct, traité par la durée de vie des sessions et la validation au niveau de l'action.
Ce qui bloque effectivement l'AiTM
La liaison à l'origine. FIDO2/WebAuthn calcule sa réponse cryptographique pour un domaine
précis. Sur service-securite-connexion.example, la réponse produite est inexploitable sur le
domaine réel. Le proxy n'a rien à relayer. C'est la seule propriété qui casse mécaniquement le
scénario au moment de la connexion.
L'absence de secret transmissible. Tant que l'échange contient une valeur qu'un tiers peut faire suivre — code, jeton d'approbation, cookie — le relais reste possible.
La preuve d'intention au moment de l'action. Si l'opération sensible elle-même exige une validation contextualisée, une session volée ne suffit plus à agir. C'est l'approche du facteur cognitif : un challenge résolu au moment de l'acte, sans secret réutilisable, dans un canal éphémère.
Que faire d'un parc déjà équipé en push
Le remplacement complet est rarement immédiat. Une trajectoire réaliste :
- Basculer les comptes à privilèges vers une méthode liée à l'origine. Population réduite, effet maximal.
- Activer le number matching et l'affichage du contexte (application demandée, localisation approximative, appareil). Cela ne stoppe pas l'AiTM, mais réduit fortement les approbations réflexes et améliore la qualité des signalements.
- Réduire la durée de vie des sessions sur les périmètres sensibles et industrialiser la révocation des jetons — c'est ce qui limite le butin réel d'un AiTM.
- Surveiller les enchaînements suspects : authentification réussie suivie d'un enregistrement d'un nouveau facteur, d'une création de règle de messagerie ou d'un changement de coordonnées.
- Ajouter une validation d'intention sur les opérations à fort impact, indépendante de la session en cours.
FAQ
Le push est-il devenu inutile ?
Non. Il reste supérieur au mot de passe seul et à l'OTP par SMS sur plusieurs plans. Mais il ne doit plus être présenté comme une protection contre le phishing moderne, ni servir seul à valider une opération sensible.
Comment repérer une session issue d'un AiTM ?
Cherchez les incohérences entre le contexte d'authentification et le contexte d'usage : adresse IP et agent utilisateur différents, géovélocité impossible, session active depuis une infrastructure d'hébergement, ou authentification suivie immédiatement d'une modification de paramètres de sécurité.
Changer le mot de passe suffit-il après un AiTM avéré ?
Non, et c'est le contresens le plus coûteux. Le butin de l'attaquant est la session, pas le mot de passe. Il faut révoquer les jetons actifs, vérifier les facteurs enrôlés et contrôler les délégations créées entre-temps.
Faut-il conserver le push comme facteur de secours ?
De préférence non sur les périmètres sensibles. Un parcours de secours faible ramène le niveau de sécurité global à celui du maillon le plus faible, et les attaquants ciblent précisément les chemins de récupération.
Aller plus loin : l'authentification cognitive · qu'est-ce qu'une MFA résistante au phishing · le QR dynamique face à l'AiTM · vol de session : ce qui reste possible