Le number matching corrige la MFA fatigue et rien d'autre. Il vérifie que la personne qui approuve regarde bien l'écran de connexion en cours ; il ne vérifie pas à qui appartient cet écran. Dans un relais par proxy inverse, la victime lit sur la page relayée le nombre généré par le service authentique, le saisit de bonne foi, et le contrôle est satisfait sans qu'aucune de ses hypothèses ait été violée.
Ce que le contrôle vérifie, terme par terme
Le mécanisme mérite d'être décrit dans le bon ordre, parce que l'ordre explique la limite. Le service qui reçoit une tentative d'authentification génère un nombre, l'affiche sur la page de connexion, puis attend que ce même nombre soit saisi dans l'application mobile de l'utilisateur. La valeur circule donc du service vers un écran, d'un écran vers un œil, d'un œil vers une saisie, puis revient au service.
Ce trajet établit une chose précise : celui qui tient le téléphone a accès visuel à la tentative en cours. C'est une liaison entre l'approbation et une tentative déterminée, ce qui suffit à écarter deux scénarios réels : l'approbation réflexe d'une demande non sollicitée, et l'approbation de la tentative d'un attaquant pendant que l'utilisateur croit valider la sienne. Le push bombing, dont la compromission d'Uber en 2022 reste le cas public le plus documenté, tombe précisément dans cette catégorie.
Ce trajet n'établit rien sur l'autre extrémité de la connexion. Aucune étape ne compare le domaine réellement joint avec le domaine attendu. Le contrôle est une liaison de tentative, jamais une liaison de destinataire.
Pourquoi l'intuition « nombre affiché = anti-phishing » échoue
L'intuition repose sur trois hypothèses implicites, et les trois sont fausses dans un scénario AiTM.
- La victime est trompée sur son intention. Elle ne l'est pas. Elle a saisi son identifiant, elle attend une demande d'approbation, elle en reçoit une. Le contrôle est conçu pour réveiller quelqu'un qui approuve sans raison ; ici, la raison existe.
- L'écran consulté est digne de confiance. Il ne l'est pas. La page affichée est produite par le proxy, qui recopie fidèlement celle du service réel, nombre inclus. L'attaquant choisit les pixels sur lesquels porte la vérification.
- Une valeur qui passe par la perception humaine est difficile à relayer. C'est l'inverse : tout ce qu'un humain peut lire et retaper, un intermédiaire peut le faire suivre. La variante téléphonique s'en passe même : un faux support technique déclenche la connexion et dicte le nombre à voix haute.
La formulation utile est celle-ci : le number matching déplace la vérification vers l'utilisateur, sur une information que l'attaquant contrôle. Un contrôle résistant au relais fait l'inverse — il confie la vérification à un logiciel, sur une information que l'attaquant ne peut pas fabriquer.
Un critère de tri applicable à n'importe quel durcissement
Quatre questions suffisent à classer un contrôle d'authentification, et elles évitent d'avoir à croire les fiches produit.
- Que vérifie-t-il exactement — une valeur, une tentative, un domaine, une action ?
- Qui choisit l'information sur laquelle porte la vérification : le service, l'utilisateur, ou l'attaquant ?
- Cette information passe-t-elle par la perception humaine ? Si oui, elle est relayable.
- Le contrôle conserve-t-il un effet une fois la session ouverte ?
| Contrôle | Ce qu'il vérifie | Qui choisit l'information vérifiée | Effet après ouverture de session |
|---|---|---|---|
| Approbation push simple | qu'un porteur d'appareil a répondu | le service | aucun |
| Number matching | que le porteur voit la tentative en cours | l'attaquant, s'il relaie l'écran | aucun |
| Contexte affiché (application, lieu, appareil) | la cohérence perçue par l'utilisateur | l'attaquant, dans les mêmes conditions | aucun |
| Limitation du nombre de demandes | un volume anormal | le service | aucun |
| Liaison à l'origine (FIDO2/WebAuthn) | le domaine réellement joint | le navigateur, hors de portée de l'utilisateur | aucun |
| Validation au niveau de l'action | qu'une opération précise a été voulue | le service, au moment de l'acte | l'opération reste bloquée |
Les quatre premières lignes portent sur la possession d'un appareil, l'attention de l'utilisateur ou le volume des demandes. Une seule porte sur l'identité du correspondant. La dernière change de plan : elle ne protège plus la connexion mais l'opération.
Ce qui casse le scénario : la liaison à l'origine
FIDO2/WebAuthn ne demande pas à l'utilisateur de reconnaître le bon site. Le navigateur calcule la réponse cryptographique en y intégrant l'origine effectivement jointe, telle que la connexion chiffrée l'a établie. Une réponse produite pour un domaine de relais n'est pas exploitable sur le domaine authentique : le proxy n'a rien à faire suivre, et la personne devant l'écran n'a aucun moyen de forcer le contraire, même de bonne volonté.
C'est la différence structurelle avec le number matching. L'un demande à l'humain de constater une cohérence ; l'autre fait constater par la machine un fait que l'humain ne peut ni voir ni contredire.
Ce que la liaison à l'origine ne couvre pas
Basculer vers un facteur lié à l'origine règle l'AiTM au moment de la connexion. Quatre chemins restent ouverts, et ce sont ceux que les attaquants empruntent quand le premier se ferme.
- Vol de session. Un cookie ou un jeton déjà émis s'utilise sans rejouer l'authentification. La méthode de connexion, quelle qu'elle soit, n'y change rien — c'est un problème de durée de vie, de révocation et de détection de jetons volés.
- Récupération de compte et enrôlement. Si un parcours de secours permet d'inscrire un nouveau facteur avec un code envoyé par courriel, le niveau réel du compte est celui de ce parcours.
- Autorisation abusive d'application. L'utilisateur s'authentifie sur le domaine authentique, la liaison à l'origine est parfaitement satisfaite, et il accorde des droits durables à une application tierce contrôlée par l'attaquant.
- Parcours multi-appareils. Les flux où un code ou un QR code affiché sur un écran est validé depuis un autre appareil réintroduisent une valeur transportable. La question à poser : le code est-il à usage unique, de très courte durée, et lié à la session précise qu'il ouvre ?
Aucun de ces quatre points ne se traite au niveau du facteur de connexion. Ils se traitent au niveau de la session, du cycle de vie des justificatifs et de l'opération.
L'arbitrage à trancher
Gardez le number matching : il coûte peu, il supprime l'approbation à l'aveugle, et il améliore la qualité des signalements utilisateurs. Reclassez-le simplement dans votre analyse de risque comme une mesure contre les attaques d'attention, sans effet contre le relais. Une matrice qui le range en face du phishing produit une couverture fictive, et cette fiction survit aux audits.
Reste l'opération sensible elle-même, qu'aucune méthode de connexion ne protège une fois la session ouverte. C'est l'objet d'une validation exigée au moment de l'acte, portant sur le contenu de l'acte : approche de l'authentification cognitive, où un challenge est résolu sans secret réutilisable, dans un canal éphémère. Sa limite doit être dite : une validation d'action rend une session volée insuffisante pour agir, elle n'empêche ni le vol de la session ni la lecture des données déjà accessibles.
FAQ
Faut-il désactiver le number matching puisqu'il ne protège pas du phishing ?
Non. Le désactiver rouvre la porte à l'approbation à l'aveugle, qui reste un vecteur exploité. Le sujet n'est pas de le retirer mais de cesser de le compter comme une mesure anti-phishing dans les tableaux de couverture.
Afficher l'application demandée et la localisation change-t-il la conclusion ?
Non, pour la même raison : ces éléments sont relayés à l'identique par le proxy, qui joint le vrai service depuis une infrastructure quelconque. Le contexte affiché aide contre les demandes totalement incongrues, pas contre un relais fidèle.
Comment vérifier si notre parc est réellement couvert contre l'AiTM ?
Listez, pour chaque population, toutes les méthodes acceptées à la connexion, y compris les méthodes de secours et les exceptions accordées. Le niveau effectif est celui de la plus faible méthode encore acceptée, jamais celui de la plus forte déployée.
Une clé physique ou une passkey suffit-elle alors ?
Elle règle le relais au moment de la connexion, ce qui est déjà considérable. Elle ne dit rien de ce qui se passe après l'ouverture de session, ni de la manière dont elle a été inscrite — deux points à instruire séparément.
Aller plus loin : le 4ᵉ facteur cognitif · mécanique d'une attaque AiTM · MFA résistante au phishing : la définition exacte · FIDO2/WebAuthn et la liaison à l'origine