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.
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 reverse proxies transparents.
Le SMS et l'email sont encore plus exposés au même relais si la page frauduleuse est convaincante.
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. Aucun code OTP à relayer, pas de mot de passe à intercepter. Même si quelqu'un intercepte le trafic, il n'obtient rien d'exploitable.
Quand vous créez vos identifiants FIDO2 sur un service, votre appareil mémorise l'adresse exacte du vrai site : pas juste « Microsoft », mais login.microsoft.com. Cette liaison (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 sera différente. login.microsoft.com.attacker.ru n'est pas login.microsoft.com. FIDO2 refuse, avant même que la connexion s'établisse.
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. Les passkeys sont désormais supportées nativement par Windows Hello, macOS, iOS, Android. 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.
Une société de 35 personnes dans la distribution, deux personnes en IT, Microsoft 365 avec MFA activé partout. 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 passent plus. Commencez par les comptes à risque : admin Microsoft 365, accès VPN à haut privilège, comptes finance ou RH.
YubiKey pour les accès critiques, passkeys pour les autres. La clé physique 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. Mais si un attaquant vole le cookie de session après une connexion réussie (session hijacking), le protocole ne peut rien. En SSO, vérifiez aussi la durée de vie des jetons OIDC.
Tester avant de déployer. Un pilote sur cinq utilisateurs pendant deux semaines évite les blocages en production.
La question n'est plus vraiment de savoir si FIDO2 vaut le coup. C'est de savoir par quels comptes commencer.
