Une attaque adversary-in-the-middle ne casse pas l'authentification : elle se place au milieu et relaie tout, en direct. Sa rentabilité repose sur une condition unique — que quelque chose de réutilisable transite. Un canal éphémère à usage unique, ouvert par un QR code dynamique, retire cette condition. Il ne supprime pas pour autant le butin final visé par l'attaquant : le jeton de session.
Ce qu'un proxy inverse capture réellement
Le déroulé d'une attaque AiTM classique, contre une MFA à secret transmissible :
- La victime arrive sur une page relais qui rejoue fidèlement l'interface du service.
- Elle saisit son identifiant et son mot de passe : le proxy les transmet au vrai service et les conserve.
- Le service demande le second facteur ; la demande est relayée à la victime.
- La victime fournit son code ou approuve la notification — de bonne foi.
- Le service émet un cookie de session, que le proxy capture.
- L'attaquant poursuit la session sans avoir besoin de refournir un seul facteur.
Deux enseignements. D'abord, les étapes 2 et 4 alimentent une réserve : identifiants et codes gardent une valeur au-delà de l'échange. Ensuite, l'étape 5 est le véritable objectif : une fois la session obtenue, la méthode d'authentification employée n'a plus d'importance.
Ce que le canal éphémère change dans ce déroulé
| Étape | MFA à secret transmissible | Canal éphémère + challenge cognitif |
|---|---|---|
| Saisie d'identifiants | collectés et rejouables | rien à saisir : approche IDless et passwordless |
| Second facteur | code ou approbation relayable | résultat lié à un challenge unique, sans valeur ensuite |
| Établissement du canal | canal durable, contrôlé par le proxy | canal chiffré temporaire, ouvert par un QR à usage unique |
| Après l'échange | la réserve reste exploitable | il ne reste rien de valorisable |
| Émission de session | cookie capturé | cookie capturé aussi — point à traiter |
La lecture honnête est celle de la dernière ligne. Aucun mécanisme d'authentification, y compris FIDO2/WebAuthn avec sa liaison à l'origine, n'empêche par lui-même qu'un jeton émis après une authentification valide soit dérobé. Ce qui change, c'est l'économie de l'attaque : sans réserve d'identifiants, l'attaquant doit être présent, en temps réel, sur chaque cible, et ne capitalise rien pour la fois suivante.
Deux stratégies complémentaires, pas concurrentes
Face à l'AiTM, deux familles de réponse existent, et elles ne traitent pas le même moment.
- La liaison à l'origine (FIDO2/WebAuthn) : la réponse cryptographique est calculée pour un domaine précis, ce qui la rend inexploitable sur un faux domaine. C'est une défense au moment de la connexion, robuste et normalisée.
- La validation au niveau de l'action : on cesse d'accorder une confiance de longue durée à une session, et l'on redemande une preuve consciente au moment de l'opération sensible. C'est une défense après la connexion, qui traite précisément l'angle mort du vol de session.
Le facteur cognitif se place sur la seconde, ce qui explique qu'il soit déployable en overlay d'une chaîne existante plutôt qu'en remplacement. Une organisation qui a investi dans des passkeys n'a pas à revenir dessus : elle complète.
Le rôle exact du QR dynamique
Il vaut la peine de préciser ce que le QR fait et ne fait pas, car la confusion est fréquente.
Ce qu'il fait : il met en relation une session ouverte sur un écran et un terminal déjà enrôlé, en ouvrant un canal éphémère et chiffré. Il est à usage unique.
Ce qu'il n'est pas : le facteur d'authentification. Celui-ci reste la résolution du challenge cognitif, c'est-à-dire l'application d'une méthode personnelle acquise lors d'un enrôlement hors ligne. Un attaquant qui obtiendrait le QR n'obtiendrait qu'une mise en relation, pas la capacité de répondre.
Et parce que l'exécution est protégée par des techniques de Moving Target Defense et de polymorphisme fonctionnel, l'observation répétée de plusieurs échanges vise à ne pas devenir capitalisable — ce qui est précisément le mode opératoire d'un proxy installé durablement.
Ce qu'il faut vérifier côté détection
Une architecture ne dispense pas de surveillance. Les signaux qui trahissent une session relayée restent les mêmes :
- écart entre l'adresse IP ou l'agent utilisateur au moment de l'authentification et pendant l'usage ;
- géovélocité incompatible entre deux événements du même compte ;
- sessions actives depuis des infrastructures d'hébergement plutôt que depuis des réseaux d'utilisateurs ;
- authentification réussie suivie immédiatement d'un changement de paramètres sensibles — adresse de contact, moyen de récupération, coordonnées bancaires.
Ces signaux alimentent le score de risque contextuel, qui peut élever l'exigence d'authentification plutôt que bloquer aveuglément.
FAQ
Un attaquant peut-il relayer le challenge cognitif en temps réel ?
Il peut relayer l'affichage, mais la réponse produite ne vaut que pour ce challenge et pour cette session. Elle ne constitue pas une réserve exploitable ensuite, ce qui retire à l'attaque sa rentabilité habituelle.
Faut-il choisir entre passkeys et facteur cognitif ?
Non. Les passkeys traitent la connexion par liaison à l'origine ; le facteur cognitif traite la validation de l'action et la preuve d'intention. Les combiner couvre deux moments différents de la même chaîne.
Comment savoir si nous sommes exposés à l'AiTM aujourd'hui ?
En listant les parcours où un code, un mot de passe ou une approbation simple sont encore acceptés, et en vérifiant la durée de vie des sessions ainsi que la capacité effective à révoquer un jeton.
Le vol de session est-il traité par cette approche ?
Partiellement, et par un autre mécanisme : en redemandant une validation consciente au moment des opérations à fort impact, un jeton volé ne suffit plus à exécuter ces opérations.
Aller plus loin : le principe du 4ᵉ facteur · l'AiTM expliqué · le QR dynamique face au phishing · le vol de session et le token theft