MFA : pourquoi toutes les authentifications fortes ne se valent pas

« Le compte est protégé, il y a du MFA. » Cette phrase ne veut presque plus rien dire : un code par SMS, une notification à approuver et une clé FIDO2 portent le même nom et n’arrêtent pas les mêmes attaques. Voici ce que la CISA et le NIST disent de ces différences, comment les contournements fonctionnent, et par où commencer quand on ne peut pas tout changer d’un coup.

Ce qu’il faut retenir

• Un facteur qu’on saisit à la main peut être relayé. Le NIST est explicite : les codes à usage unique et les codes reçus par un autre canal ne sont pas résistants à l’hameçonnage, car la saisie ne lie pas le code à la session authentifiée.
• La CISA classe le MFA en quatre niveaux. Seules FIDO/WebAuthn et l’authentification par PKI résistent à l’hameçonnage ; le SMS et la voix sont un « dernier recours ».
• La fatigue MFA est un cas réel : en 2022, Uber a reconnu qu’un prestataire avait fini par accepter l’une des demandes d’approbation répétées d’un attaquant qui avait son mot de passe.
• Le maillon faible est souvent la récupération : selon l’avis conjoint sur Scattered Spider, le groupe convainc le support informatique de réinitialiser le mot de passe et de transférer le MFA vers un appareil qu’il contrôle.
• Priorité : commencer par les comptes qui donnent le plus de pouvoir (administrateurs, messagerie, VPN), avec deux clés par compte et le SMS retiré de la récupération de ces comptes.

Le MFA n’est pas un bloc

Le MFA consiste à demander au moins deux types de preuves : quelque chose que l’on sait, que l’on possède, que l’on est. La fiche « Implementing Phishing-Resistant MFA » de la CISA (octobre 2022) pose le constat sans détour : toutes les formes de MFA ne sont pas également sûres. Certaines sont vulnérables à l’hameçonnage, au « push bombing », à l’exploitation du protocole SS7 et au détournement de carte SIM.

Sa table 1 range les méthodes de la plus forte à la plus faible. En voici la synthèse, fidèle à ses conclusions :

Un point mérite d’être noté : la CISA ne dit pas que les codes d’application ou les notifications avec correspondance de nombre sont inutiles. Elle les décrit comme les meilleures options pour les petites et moyennes structures qui ne peuvent pas migrer immédiatement vers une méthode résistante à l’hameçonnage. Mais elle précise qu’elles restent vulnérables à l’hameçonnage. Et rappelle que n’importe quel MFA vaut mieux que pas de MFA.

Ce que le NIST ajoute

La révision 4 de la publication NIST SP 800-63B (lignes directrices sur l’identité numérique) est plus précise sur trois points :

• Définition. La résistance à l’hameçonnage est « la capacité du protocole d’authentification à empêcher la divulgation des secrets d’authentification et des sorties valides de l’authentificateur à un vérificateur usurpateur, sans dépendre de la vigilance de l’utilisateur ». Le protocole, pas l’utilisateur, doit faire le travail.
• Règle sur la saisie manuelle. Les authentificateurs qui impliquent la saisie manuelle d’une valeur (codes reçus par un autre canal, codes à usage unique) « ne doivent pas être considérés comme résistants à l’hameçonnage », parce que la saisie ne lie pas la valeur à la session authentifiée : un vérificateur usurpateur peut relayer la valeur et s’authentifier.
• Deux mécanismes reconnus : la liaison de canal (par exemple TLS avec certificat client, utilisé par les cartes PIV et CAC) et la liaison au nom du vérificateur, dont WebAuthn est l’exemple donné : le secret est choisi en fonction du nom de domaine authentifié du site.

Le NIST écarte aussi deux pratiques courantes. La méthode qui se contente de demander l’approbation d’une requête sur le second canal, au lieu d’exiger le transfert d’un secret, « n’est plus considérée comme acceptable » : le NIST cite explicitement les attaques de fatigue d’authentification. Et l’email « ne doit pas » servir de canal d’authentification hors bande. Le téléphone public (SMS, voix) reste possible mais « restreint ».

Sur les clés d’accès synchronisées (passkeys), l’annexe B du même document précise : synchroniser une clé la rend exportable, ce qui est compatible avec le niveau AAL2 sous conditions, mais viole les exigences de non-exportabilité du niveau AAL3 (voir l’annexe B). Pour le plus haut niveau d’assurance, il faut donc une clé qui ne quitte jamais son support matériel.

Comment le contournement fonctionne

Le relais d’hameçonnage : le code n’a pas de destinataire

Un code TOTP (le code à six chiffres d’une application d’authentification) est calculé à partir d’un secret partagé et de l’heure. Il ne contient aucune information sur le site auquel il est destiné. Voici l’algorithme complet en Python, testé avec les vecteurs de la RFC 6238 :

import hmac, hashlib, struct

def totp(secret: bytes, t: int, digits=6, step=30) -> str:
    h = hmac.new(secret, struct.pack(">Q", t // step), hashlib.sha1).digest()
    o = h[-1] & 0x0F
    return str((struct.unpack(">I", h[o:o+4])[0] & 0x7FFFFFFF) % 10**digits).zfill(digits)

# Vecteurs de test RFC 6238 (SHA-1, secret ASCII « 12345678901234567890 », 8 chiffres)
# totp(secret, 59,         8) -> 94287082   OK
# totp(secret, 1111111109, 8) -> 07081804   OK
# totp(secret, 2000000000, 8) -> 69279037   OK

Nous avons vérifié les cinq vecteurs de la RFC ; tous concordent. Le code est valable pour n’importe quel vérificateur qui connaît le secret, pendant sa fenêtre de validité. Si un faux site le relaie au vrai site dans les trente secondes, il fonctionne.

C’est exactement ce que fait Evilginx, décrit par son auteur comme « un cadre d’attaque par interposition utilisé pour hameçonner des identifiants ainsi que des cookies de session, ce qui permet de contourner la protection par authentification à deux facteurs ». Le faux site sert de proxy inverse vers le vrai : l’utilisateur voit la vraie page, saisit son mot de passe et son code, et l’attaquant récupère le cookie de session qui en résulte. Le projet précise lui-même qu’il est destiné aux tests d’intrusion légitimes.

Avec WebAuthn, le navigateur ne signe que pour le domaine auquel la clé a été enregistrée : sur un faux domaine, la clé n’a rien à signer, et l’utilisateur n’a rien à « repérer ». C’est le sens de la « liaison au nom du vérificateur » du NIST. La spécification Web Authentication niveau 3 (recommandation du W3C du 25 août 2026) définit chaque identifiant public comme lié à une partie de confiance donnée.

La fatigue MFA : Uber, 2022

Dans sa mise à jour du 19 septembre 2022 (annexée à un dépôt auprès de la SEC), Uber écrit qu’un prestataire externe avait vu son compte compromis : l’attaquant avait « vraisemblablement acheté » son mot de passe sur le dark web, après l’infection de son appareil personnel par un logiciel malveillant. Il a ensuite tenté de se connecter à répétition ; « à chaque fois, le prestataire recevait une demande d’approbation à deux facteurs, qui bloquait d’abord l’accès. Finalement, il en a accepté une, et l’attaquant s’est connecté ». Uber ajoute renforcer ses politiques d’authentification multifacteur.

La même technique est décrite par la CISA pour le groupe Scattered Spider dans l’avis conjoint AA23-320A (publié le 16 novembre 2023, mis à jour le 29 juillet 2025) : envoi répété de notifications jusqu’à ce que l’employé appuie sur « Accepter » (MFA fatigue), mais aussi appels au support en se faisant passer pour un employé, transfert du MFA vers un appareil contrôlé par l’attaquant, et détournement de carte SIM.

Le support informatique : la porte de derrière

Le même avis décrit une séquence qui n’attaque aucune technologie : le groupe se fait passer pour un employé auprès du support, obtient la réinitialisation du mot de passe, puis le transfert du MFA vers un appareil qu’il contrôle. Une fois le compte pris, il enregistre ses propres jetons MFA et installe des outils d’administration à distance pour rester en place.

Conséquence pratique : un MFA résistant à l’hameçonnage ne vaut que par sa procédure de récupération. Si un appel au support suffit à enregistrer un nouveau facteur, l’attaquant n’a pas besoin de casser quoi que ce soit.

Un plan réaliste, dans l’ordre

1. Identifier les comptes à privilèges : administrateurs, messagerie, VPN, console de sauvegarde, gestion des identités. Ce sont eux qui reçoivent le meilleur niveau en premier (la CISA le recommande d’abord aux « administrateurs système et autres cibles de grande valeur »).
2. Deux clés FIDO2 par compte (une principale, une de secours conservée ailleurs). Une seule clé perdue sans remplaçante, c’est une procédure de récupération à haut risque.
3. Retirer le SMS et la voix des comptes à privilèges, y compris comme option de secours : une méthode de repli faible annule la méthode forte, car l’attaquant choisit le repli.
4. Là où la migration est impossible (application ancienne, prestataire), activer au minimum la correspondance de nombre pour les notifications (solution intermédiaire recommandée par la CISA) et limiter leur fréquence d’envoi (demandé par le NIST côté vérificateur).
5. Durcir la récupération : vérification d’identité renforcée pour la réinitialisation d’un facteur, rappel sur un numéro connu, délai et notification sur un autre canal, approbation d’un tiers pour les comptes à privilèges.
6. Surveiller les enregistrements de nouveaux facteurs et les connexions depuis un nouvel appareil : c’est la trace que laisse la prise de contrôle décrite plus haut.

Les pièges à éviter

• Croire qu’une notification avec correspondance de nombre est résistante à l’hameçonnage. Elle arrête le bombardement de notifications ; elle ne rend pas un faux site inopérant.
• Garder le SMS en secours : l’attaquant se rabat sur la méthode la plus faible autorisée.
• Une seule clé, sans secours : le premier verrouillage vire à l’incident, et pousse à assouplir la récupération.
• Ne protéger que la connexion, pas la session : les cookies volés après authentification contournent le MFA. Durée de session raisonnable, et liaison de la session à l’appareil quand la plateforme le permet.
• Oublier les comptes de service et l’accès hérité (protocoles anciens, mots de passe d’application) qui ne demandent aucun second facteur.
• Traiter la fatigue MFA comme un problème d’utilisateurs : le NIST demande au contraire une limite de fréquence des notifications côté vérificateur.

Six questions pour votre organisation

1. Quels comptes administrateurs, VPN et messagerie utilisent encore un SMS, un code ou un push simple ?
2. Une notification d’approbation peut-elle arriver sans que l’utilisateur ait rien saisi ?
3. Que faut-il, précisément, à un appelant pour faire réinitialiser un facteur MFA ?
4. Qui est alerté lorsqu’un nouveau facteur est enregistré sur un compte à privilèges ?
5. Chaque compte à privilèges a-t-il une clé de secours, et où est-elle conservée ?
6. Existe-t-il encore des accès (protocoles anciens, mots de passe d’application) qui contournent complètement le second facteur ?

En résumé

« Avoir du MFA » n’est plus une réponse. La question utile est : que fait l’attaquant qui a déjà le mot de passe, et qui peut interposer un faux site ou appeler le support ? Avec un code ou une notification, la réponse est « il peut s’en sortir » ; avec une clé FIDO2 ou une carte à puce, l’authentification lui est refusée par construction. Passer à ces méthodes pour les comptes à privilèges, retirer les replis faibles et durcir la récupération est l’un des meilleurs rapports effort/résultat de ce domaine, à notre avis. C’est aussi la recommandation constante des avis conjoints sur les rançongiciels, comme celui que nous détaillons dans notre article sur les rançongiciels.

Transparence : cet article a été rédigé avec l’aide d’un assistant Claude. Les classements et citations proviennent de la fiche CISA d’octobre 2022, de la publication NIST SP 800-63B-4 (pages officielles), de l’avis AA23-320A, du communiqué d’Uber du 19 septembre 2022 et de la spécification W3C, relus sur les pages sources en septembre 2026 ; les citations sont traduites de l’anglais. L’algorithme TOTP a été exécuté et vérifié contre la RFC 6238. Le plan d’action et les pièges sont l’avis de l’auteur.

À lire aussi

• Rançongiciels : ce qui se passe avant le chiffrement : des identifiants valides à l’écran de rançon, deux chronologies réelles.
• Active Directory : les chemins les plus courts vers Domain Admin : ce que l’attaquant fait une fois authentifié.

Sources

• CISA, « Implementing Phishing-Resistant MFA » (octobre 2022) : cisa.gov
• NIST, SP 800-63B-4, « Authenticators » et annexe B (authentificateurs synchronisables) : pages.nist.gov ; annexe B
• Uber, mise à jour du 19 septembre 2022 (pièce jointe 99.1 d’un formulaire 8-K) : sec.gov
• CISA, FBI et partenaires, « Scattered Spider » (AA23-320A) : cisa.gov
• Evilginx, dépôt du projet : github.com/kgretzky/evilginx2
• W3C, « Web Authentication: An API for accessing Public Key Credentials, Level 3 » : w3.org
• IETF, RFC 6238, « TOTP: Time-Based One-Time Password Algorithm » : rfc-editor.org