« Avons-nous la MFA ? » est une question à laquelle on répond oui. « Notre MFA résiste-t-elle au relais ? » est une question à laquelle on répond par un test. Ce protocole en six points se conduit sur votre propre environnement, sans outil offensif : il repose sur l'observation de ce que votre système accepte, pas sur la simulation d'une attaque.
Ce que ce protocole établit, et ce qu'il ne remplace pas
Il répond à une question précise : votre chaîne d'authentification transmet-elle une valeur qu'un tiers pourrait réutiliser ? C'est le critère qui sépare une MFA contournable d'une MFA résistante.
Il ne remplace ni un test d'intrusion, ni un audit de conformité. Un pentest cherche des failles d'implémentation ; ce protocole qualifie une propriété de conception. Les deux sont complémentaires, et celui-ci a l'avantage de pouvoir être refait à chaque changement de configuration.
Deux précautions avant de commencer : conduisez ces tests sur des comptes de test dédiés, et prévenez votre équipe de détection — plusieurs de ces manipulations généreront des alertes, ce qui est en soi une information utile.
Test 1 — Inventorier ce qui est réellement accepté
Objectif : établir la liste des méthodes acceptées par parcours, et non celle des méthodes déployées. L'écart entre les deux est le premier angle mort.
Pour chaque parcours d'authentification, notez quelles méthodes aboutissent réellement à une session ouverte. Vérifiez en particulier :
- les chemins historiques encore actifs (un ancien portail, un accès VPN, une API) ;
- les exceptions accordées à des populations spécifiques ;
- les comptes de service et les comptes techniques ;
- les accès des prestataires.
Critère de réussite : vous pouvez produire un tableau parcours × méthodes acceptées, sans case « probablement ». Une seule méthode faible encore acceptée sur un parcours en définit le niveau réel.
Test 2 — Vérifier si la réponse est liée à l'origine
C'est le test central. Une méthode est résistante au relais si sa réponse est calculée pour un domaine donné et devient inexploitable ailleurs.
| Méthode | Question à se poser | Verdict attendu |
|---|---|---|
| Mot de passe | la valeur saisie fonctionne-t-elle ailleurs ? | rejouable |
| SMS-OTP, OTP e-mail | le code est-il valable quel que soit le site qui le réclame ? | rejouable |
| TOTP | le code dépend-il du domaine ? non, seulement du temps | rejouable |
| Notification push | l'approbation dépend-elle du domaine visité ? | rejouable |
| Passkey / FIDO2 | l'assertion est-elle liée à l'origine ? | non rejouable en connexion |
| Clé de sécurité | idem | non rejouable en connexion |
Le test pratique tient en une observation : si un code ou une approbation peut être obtenu par un tiers puis présenté au service légitime, la méthode est rejouable. Aucun réglage ne corrige cela — c'est une propriété de la méthode.
Point souvent mal compris : la correspondance de numéro (number matching) ne change pas ce verdict. Elle empêche une approbation à l'aveugle, donc traite la MFA fatigue, mais dans un relais la victime s'authentifie volontairement et saisit le nombre qui lui est transmis. Le détail est développé dans l'article consacré aux limites du number matching.
Test 3 — Mesurer ce que vaut la session
Une authentification résistante suivie d'une session permissive déplace le problème sans le résoudre.
- Ouvrez une session sur un compte de test et relevez la durée de vie du jeton.
- Exportez le jeton de session, puis présentez-le depuis une autre adresse IP et un autre agent.
- Observez : la session est-elle acceptée ? Une alerte est-elle levée ?
- Révoquez la session côté administration et vérifiez le délai réel avant que l'accès cesse.
Critère de réussite : le rejeu depuis un contexte différent est détecté ou refusé, et la révocation est effective en secondes. Si un jeton exporté fonctionne ailleurs sans réaction, le vol de session est un chemin ouvert quelle que soit la qualité de la connexion initiale.
Test 4 — Attaquer le parcours de récupération
C'est le test qui remonte le plus de mauvaises surprises, parce qu'on déploie une méthode forte et qu'on laisse le secours retomber sur un facteur faible.
Sur un compte de test, déclenchez chaque scénario de perte et notez ce qui est exigé :
- appareil perdu ;
- numéro de téléphone changé ;
- accès à la boîte mail perdu ;
- demande de réinitialisation auprès du support ;
- collaborateur en déplacement, sans son second facteur.
Critère de réussite : aucun de ces chemins ne permet de reprendre la main avec une méthode plus faible que le facteur principal. Le support, en particulier, ne doit pas pouvoir contourner l'authentification sur la seule base d'informations qu'un attaquant peut connaître ou deviner.
Test 5 — Distinguer connexion et action
Vérifiez si une opération à impact réel exige une validation propre, ou si elle hérite simplement de la session ouverte le matin.
Choisissez trois actions sensibles — un virement, un changement de coordonnées bancaires, une élévation de privilèges. Pour chacune : l'action demande-t-elle une nouvelle preuve ? Cette preuve affiche-t-elle le contexte de l'opération (montant, bénéficiaire, cible) ou seulement « validez la demande » ?
Critère de réussite : sur une action irréversible, l'utilisateur voit ce qu'il valide. Une demande d'approbation sans contexte est précisément ce qu'exploite la fraude au faux conseiller, puisque la victime croit valider autre chose.
Test 6 — Vérifier ce que vous pourriez produire six mois plus tard
Simulez une contestation : sélectionnez une opération réalisée par un compte de test, puis demandez à votre équipe de reconstituer le dossier.
Ce qui doit ressortir : quelle méthode a été employée, à quel moment, depuis quel contexte, sur quelle action précise — et non seulement « une session a été ouverte ». Si le journal atteste la session mais pas l'opération, la traçabilité attendue par NIS2 et DORA est incomplète. La valeur probante d'un journal mérite d'être examinée pour elle-même.
Restituer les résultats
Un résultat exploitable ne se présente pas en liste de failles, mais en tableau de décision : pour chaque parcours, le niveau constaté, le risque résiduel accepté, et l'action décidée. C'est ce format qui permet un arbitrage — voir la méthode pour présenter le risque à une direction.
Les tests 2 et 5 sont ceux qui déterminent si votre dispositif prouve une intention ou seulement la présence d'un secret. C'est la question à laquelle répond le 4ᵉ facteur cognitif.
FAQ
Faut-il des compétences offensives pour conduire ces tests ?
Non. Aucun test ci-dessus ne demande de monter une attaque : il s'agit d'observer ce que votre système accepte, refuse et journalise. Un pentest reste utile, mais pour d'autres questions.
Ces tests remplacent-ils un audit de conformité ?
Non. Un audit vérifie la conformité à un référentiel ; ce protocole qualifie la résistance réelle. Les deux se nourrissent : les résultats des tests 4 et 6 alimentent directement un dossier d'audit.
À quelle fréquence les refaire ?
À chaque changement de configuration de l'IdP, à chaque ajout d'application, et après toute évolution du parcours de récupération. Ce sont les trois moments où une méthode faible se réintroduit sans qu'on le décide.
Que faire si un test échoue sur un système historique impossible à modifier ?
Documentez-le comme risque résiduel assumé, et réduisez son périmètre plutôt que sa probabilité : restreignez les populations, raccourcissez les sessions, isolez les accès. Un risque nommé et borné se gouverne ; un risque implicite, non.
Aller plus loin : pilier : authentification cognitive · MFA résistant au phishing · auditer ses parcours de récupération · modéliser la menace d'un parcours