Votre équipe a activé le MFA. L'app authenticator tourne, les codes OTP défilent toutes les trente secondes. Et ce mois-ci, un compte est quand même compromis.
Ce n'est pas un scénario théorique. C'est ce qui se passe quand une attaque man-in-the-middle est bien construite. Le code OTP ? Relayé en temps réel, avant même qu'il n'expire. La session ? Volée une fois l'authentification passée. FIDO2 et les passkeys ont été conçus pour bloquer précisément ce vecteur. Voici comment ça marche et là où ça reste encore incomplet.
Le MFA classique face aux attaques MITM : un problème de timing
Une attaque MITM sur un processus d'authentification ne cherche pas à casser un chiffrement. Elle se glisse entre l'utilisateur et le service cible, relaie les échanges en temps réel, et intercepte ce qui circule.
Pour un code OTP à six chiffres, la fenêtre est de trente secondes. C'est largement suffisant. L'attaquant présente une fausse page de connexion, récupère les identifiants et le code OTP saisi, les transmet immédiatement au vrai service, obtient la session et disparaît. Des outils comme Evilginx ou Modlishka automatisent ce type d'attaque : ils fonctionnent comme des reverses proxy transparents. L'utilisateur croit se connecter à son vrai service. Il se connecte en réalité à un relais qui copie tout.
Le SMS et l'email sont encore plus exposés et son vulnérable au même relais si la page frauduleuse est convaincante.
Ce que FIDO2 change fondamentalement
FIDO2 / WebAuthn repose sur une mécanique radicalement différente. Lors de la première connexion, votre dispositif génère une paire de clés cryptographiques : une clé privée (qui ne quitte jamais l'appareil ou la clé physique) et une clé publique enregistrée côté service.
Aucun secret ne transite lors de l'authentification. Le service envoie un défi aléatoire, votre appareil le signe avec la clé privée, le service vérifie la signature avec la clé publique et c'est finit. Aucun code OTP à relayer, pas de mot de passe à intercepter.
Concrètement : votre téléphone ou votre clé d'accès (Yubikey par exemple) stocke une clé privée qui ne peut pas être exportée. La connexion s'effectue localement sur votre appareil. Le réseau ne voit que la signature, pas le secret. Même si quelqu'un intercepte le trafic, il n'obtient rien d'exploitable.
Pourquoi le faux site ne trompe plus FIDO2
Quand vous créez vos identifiants FIDO2 sur un service, votre appareil mémorise l'adresse exacte du vrai site et pas juste « Microsoft », mais login.microsoft.com. Cette liaison (qu'on appelle l'origin binding) fait que la clé cryptographique ne fonctionnera jamais sur une autre adresse, même très ressemblante.
Si un attaquant crée une copie parfaite de la page Microsoft, même avec un cadenas HTTPS vert l'adresse du site sera différente. login.microsoft.com.attacker.ru n'est pas login.microsoft.com. FIDO2 refuse. L'utilisateur n'a rien à comparer, rien à vérifier. Le protocole le fait à sa place, avant même que la connexion s'établisse.
Pourquoi les PME doivent s'y intéresser
Le phishing avancé et les attaques MITM ne ciblent plus seulement les grandes entreprises. Les petites structures sont souvent plus accessibles : moins de ressources sécurité, plus de comptes admin partagés, moins de surveillance des connexions anormales.
Un ransomware qui commence par un compte Microsoft 365 compromis peut paralyser une PME de trente personnes en quelques heures. Le coût moyen d'un incident de ce type en Europe dépasse aujourd'hui 100 000 CHF en pertes directes, sans compter l'exposition de données personnelles sous LPD ou RGPD.
Les passkeys sont désormais supportées nativement par Windows Hello, macOS, iOS, Android. Microsoft, Google et Apple les poussent comme remplacement des mots de passe. Pour une PME qui gère ses identités via Entra ID, la migration vers FIDO2 est plus courte qu'elle n'y paraît.
Note : le scénario ci-dessous est hypothétique, mais représentatif de situations documentées par l'ANSSI et le CISA.
Exemple concret ou retour terrain
Une société de 35 personnes dans le secteur de la distribution, deux personnes en IT, Microsoft 365 avec MFA activé sur tous les comptes. Un responsable commercial clique sur un email d'hameçonnage. La page ressemble trait pour trait à la connexion Microsoft. Il saisit ses identifiants, valide l'OTP et l'attaquant dispose d'un cookie de session valide pendant huit heures.
Migration FIDO2 réalisée quelques semaines plus tard : YubiKey sur les comptes à privilèges, passkeys Windows Hello pour les autres. Les tentatives de phishing continuent d'arriver mais ne passeront plus.
Commencer par les comptes à risque : Admin Microsoft 365, accès VPN avec haut privilège, comptes avec accès finance ou RH. Pas besoin de migrer tout le monde en une fois, concentrez l'effort là où une compromission fait le plus de dégâts.
Ce qu'on recommande chez Logexia
YubiKey pour les accès critiques, passkeys pour les autres. La clé physique (YubiKey, Feitian ePass) reste la référence pour les comptes sensibles. Les passkeys logicielles (Windows Hello, iCloud Keychain) conviennent très bien pour les utilisateurs standard. La coexistence des deux est possible dans Entra ID.
Être clair sur ce que FIDO2 ne protège pas. L'origin binding bloque l'attaque MITM sur l'authentification elle-même. Mais si un attaquant vole le cookie de session après une connexion réussie (session hijacking), le protocole ne peut rien. En environnement SSO, vérifier aussi la durée de vie des jetons OIDC car des jetons trop longtemps valides restent une surface d'attaque réelle.
Tester avant de déployer. Un pilote sur cinq utilisateurs pendant deux semaines évite les blocages en production. La plupart des utilisateurs s'adaptent en moins d'une heure.
FIDO2 n'est pas parfait. Rien ne l'est en sécurité.
Mais sur le vecteur des attaques MITM et du phishing de credentials, les deux causes les plus fréquentes de compromission de compte en PME, FIDO2 apporte une protection que le MFA classique ne peut pas offrir structurellement.
Conclusion
La question n'est plus vraiment de savoir si FIDO2 vaut le coup. C'est de savoir par quels comptes commencer.