Face à une attaque AiTM (adversary-in-the-middle), le facteur cognitif oppose une propriété précise : ce qui transite ne peut pas être rejoué. Le défi est résolu dans un canal éphémère ouvert par QR code dynamique à usage unique, et le polymorphisme fonctionnel fait varier les paramètres en continu. Un proxy inverse peut donc relayer l'échange sans en tirer une réponse utilisable. Mais l'AiTM ne vise pas seulement l'échange : il vise la session qui suit. C'est là que la réponse doit être nuancée.
Ce que capte réellement un proxy inverse
Un relais opère à deux niveaux successifs, souvent confondus dans les analyses.
Le niveau de l'échange d'authentification. L'attaquant transmet les données saisies vers le service légitime et les réponses en sens inverse. C'est ce niveau qui rend le SMS-OTP, le TOTP et le push inopérants : la valeur transmise est valide quelques dizaines de secondes, ce qui suffit largement à un automate.
Le niveau du résultat. Une fois l'authentification acceptée, le service émet un cookie de session et, souvent, un jeton de rafraîchissement. L'attaquant les capture et poursuit sans avoir besoin d'aucun facteur.
Le facteur cognitif traite le premier niveau par construction. Il ne traite le second que si la preuve est ancrée sur l'action — et c'est un choix d'architecture, pas une propriété automatique.
Pourquoi le relais échoue au premier niveau
Trois mécanismes se combinent.
L'absence de valeur statique. Rien de ce que détient l'utilisateur ne constitue un secret transmissible. Le relais n'a donc aucune donnée à capturer pour un usage ultérieur.
Le canal éphémère. Le QR code dynamique à usage unique ouvre un canal chiffré propre à la sollicitation en cours. Il n'existe plus après, et il ne peut pas être ouvert à nouveau avec les mêmes éléments.
L'exécution mouvante. Le Moving Target Defense et le polymorphisme fonctionnel font varier les paramètres de l'échange. Un attaquant qui observerait plusieurs sessions ne construirait pas un modèle stable exploitable.
Une comparaison éclaire ce point : FIDO2/WebAuthn obtient une résistance équivalente au relais par un mécanisme différent, la liaison à l'origine. Le résultat est comparable sur la connexion ; les propriétés diffèrent sur ce qui vient après.
Ce qui reste possible pour l'attaquant
| Étape de l'AiTM | Facteur cognitif | Commentaire |
|---|---|---|
| Servir une page relais crédible | Ne l'empêche pas | Aucun facteur n'empêche l'affichage d'une page |
| Capturer un secret saisi | Sans objet | Il n'y a pas de secret à saisir |
| Relayer une réponse pour ouvrir une session | Bloqué | Réponse non rejouable, canal éphémère |
| Voler un cookie de session déjà émis | Non bloqué par le facteur seul | Traité par la validation par action |
| Voler un jeton de rafraîchissement | Non bloqué par le facteur seul | Durée de vie et révocation à traiter |
| Agir dans la session volée | Bloqué sur les gestes protégés | Chaque action sensible exige une nouvelle preuve |
| Enrôler un facteur attaquant | Dépend du parcours d'enrôlement | À protéger explicitement |
Les lignes quatre et cinq méritent d'être assumées. Aucun facteur d'authentification, quel qu'il soit, ne protège un jeton de session une fois celui-ci émis. Prétendre le contraire serait inexact, et un RSSI le verrait immédiatement.
La réponse au second niveau : ancrer la preuve sur l'action
La différence pratique tient à ce que l'on protège. Si le facteur cognitif ne sert qu'à ouvrir une session, l'attaquant qui vole cette session obtient tout ce qui suit — exactement comme avec une passkey.
Si la preuve est exigée au moment de chaque opération sensible, la session volée perd l'essentiel de sa valeur. L'attaquant peut consulter, mais il ne peut ni virer, ni modifier des coordonnées bancaires, ni créer un compte à privilèges, faute de pouvoir résoudre le défi correspondant.
C'est ce qu'on appelle l'authentification transactionnelle, et c'est l'usage pour lequel le facteur cognitif apporte le plus. La recommandation opérationnelle qui en découle est claire : définir la liste des gestes qui exigent une preuve, plutôt que de raisonner uniquement en termes d'ouverture de session.
Détection : ce que le dispositif rend visible
Un effet secondaire mérite d'être noté. Lorsqu'une preuve d'intention est exigée par action, chaque opération sensible produit un événement daté, associé à une personne et à un contexte. Une tentative d'exploitation depuis une session volée se traduit alors par un défi non résolu ou abandonné — signal exploitable qu'une architecture fondée sur la seule ouverture de session ne produit jamais.
Combiné à un score de risque contextuel, cela permet d'élever l'exigence lorsque le contexte diverge : adresse d'hébergeur, appareil inconnu, horaire inhabituel, séquence anormale. Le facteur cognitif s'inscrit ainsi dans une logique proche de l'architecture Zero Trust du NIST SP 800-207 : ne jamais faire confiance, toujours vérifier — y compris à l'intérieur d'une session déjà ouverte.
FAQ
Le facteur cognitif rend-il l'AiTM impossible ?
Il rend le relais inopérant sur l'échange d'authentification. Il ne rend pas impossible le vol d'un cookie de session obtenu autrement, par exemple via un logiciel malveillant sur le poste. La protection complète suppose d'ancrer la preuve sur les actions.
En quoi diffère-t-il d'une passkey face à l'AiTM ?
Les deux bloquent le relais, par des mécanismes différents : liaison à l'origine pour la passkey, absence de rejouabilité et exécution mouvante pour le facteur cognitif. La différence porte sur l'après : le facteur cognitif est conçu pour valider une action, pas seulement une connexion.
Faut-il exiger une preuve à chaque clic ?
Non, et ce serait contre-productif. La friction doit se concentrer sur un nombre restreint de gestes à fort impact, définis avec les métiers. Une exigence généralisée recrée exactement l'automatisme que l'on cherche à éviter.
Comment traiter les sessions déjà ouvertes lors d'un incident ?
Par une révocation centralisée, testée à l'avance, incluant les jetons de rafraîchissement. Cette capacité relève de l'architecture de session et reste nécessaire quel que soit le facteur choisi.
Aller plus loin : authentification cognitive · anatomie de l'attaque AiTM · QR dynamique contre l'AiTM · authentification transactionnelle