La fuite Free. Avant ça, Viamedis et Almerys. Avant ça, d’autres. À chaque incident, le même cycle : annonce, couverture médiatique, conseils de sécurité. Des conseils qui n’ont guère évolué depuis vingt ans.
En 2025, les credentials fuitent. C’est une donnée de base, pas une hypothèse de travail. Partir de là change ce qu’on cherche à résoudre : non plus protéger le mot de passe, mais concevoir l’authentification pour qu’un mot de passe volé ne suffise pas à ouvrir un compte. C’est cette bascule qui mène au MFA, et qui explique pourquoi tous les MFA ne se valent pas.
Les deux vecteurs : ils ne fonctionnent pas de la même façon
Le credential stuffing : le mot de passe volé
Une fuite expose des couples email/mot de passe, voire des hashes que l’on peut craquer. L’attaquant ne cherche pas à cibler un compte précis : il teste automatiquement ces couples sur des milliers de services. Ça marche parce que les mots de passe sont réutilisés. Un compte compromis sur un site en 2021 peut ouvrir un accès à une messagerie professionnelle en 2026 si le mot de passe n’a pas changé.
Oui, changer son mot de passe après une fuite coupe ce vecteur. Mais c’est une réponse à la dernière attaque, pas à la prochaine.
Le phishing : le mot de passe donné
Le phishing ne nécessite pas de fuite. Un email convaincant, une page de connexion clonée, et l’utilisateur saisit lui-même ses identifiants sur le faux site. La force du mot de passe ne change rien : un mot de passe de 32 caractères phishé est aussi utile à l’attaquant qu’un mot de passe de 8 caractères.
C’est le vecteur de loin le plus documenté dans les compromissions réelles d’entreprise. Le rapport Verizon DBIR le confirme année après année : le phishing est le premier mode d’accès initial dans les incidents sérieux, devant le brute force, devant le cracking.
Ce que le MFA résout, et ce qu’il ne résout pas
Contre le credential stuffing : le TOTP suffit
Un utilisateur avec un TOTP actif rend le mot de passe volé inutilisable. L’attaquant dispose du bon identifiant et du bon mot de passe : la connexion échoue quand même. Il lui manque le second facteur, stocké sur l’appareil de l’utilisateur légitime, jamais exposé dans la base de données compromise.
Le MFA transforme la fuite de credentials en incident sans suite opérationnelle directe pour le compte concerné. C’est considérable.
Un mot sur le MFA par SMS : il améliore la situation par rapport à l’absence de MFA. Mais il reste vulnérable au SIM swapping, un transfert frauduleux du numéro de téléphone obtenu par ingénierie sociale auprès de l’opérateur. Pour des accès sans enjeu particulier, il peut être une étape de transition. Pour des comptes critiques, il ne constitue pas un niveau d’assurance suffisant.
Contre le phishing : uniquement FIDO2
Le TOTP ne protège pas contre le phishing en temps réel. Les attaques AiTM (Adversary-in-the-Middle) proxifient la connexion : l’utilisateur entre ses identifiants sur le faux site, l’attaquant les relaie immédiatement vers le vrai site, code TOTP inclus, dans la fenêtre des 30 secondes. La session légitime est capturée.
FIDO2 (passkeys, clés physiques type YubiKey) ferme ce vecteur par construction. La clé privée signe un challenge lié au domaine exact du site. Un faux site, même un clone pixel-perfect, ne peut pas recevoir une signature valide pour le vrai site. L’authentification est cryptographiquement liée à l’origine. Le phishing échoue, quelles que soient les techniques d’ingénierie sociale employées.
| Vecteur | Sans MFA | MFA SMS | TOTP / clé physique | FIDO2 |
|---|---|---|---|---|
| Credential stuffing | Exposé | Protégé | Protégé | Protégé |
| SIM swapping ciblé | Exposé | Exposé | Protégé | Protégé |
| Phishing AiTM | Exposé | Exposé | Exposé | Protégé |
Ce n’est pas une différence de degré entre les niveaux. C’est une différence de nature.
FIDO2 soulève des questions concrètes avant le déploiement : fallback pour les appareils non compatibles, récupération de compte, passkeys synchronisés vs liés au hardware. Notre article sur le sujet couvre ces points.
Le problème concret : les systèmes qui ne savent pas faire ça
La plupart des organisations qui n’ont pas encore déployé de MFA fort n’ont pas de problème de conviction : elles ont un problème d’architecture.
Les systèmes legacy authentifient souvent directement contre un annuaire LDAP maison, une base utilisateurs custom, ou une couche d’authentification écrite il y a quinze ans. Intégrer FIDO2 dans ce type de système sans toucher au code applicatif est généralement impossible.
La réponse n’est pas de réécrire l’application. C’est d’introduire une couche d’identité en frontal : un fournisseur d’identité (IdP) qui gère l’authentification, le MFA et les sessions, et auquel l’application délègue via OIDC ou SAML. L’application legacy vérifie un token. Elle ne sait plus rien des mots de passe, des codes TOTP ou des clés FIDO2.
Selon les contextes, cette couche prend des formes différentes : Keycloak pour les déploiements qui demandent de la customisation et du contrôle sur l’infrastructure (nous l’avons mis en œuvre notamment pour Erganeo), intégration des solutions Microsoft Entra ID ou Google Identity pour les environnements qui s’appuient sur ces écosystèmes, ou développement d’un serveur OIDC sur mesure quand les contraintes métier ou réglementaires l’exigent. C’est le cas du service d’authentification que nous développons et maintenons pour une organisation professionnelle réglementée du secteur du chiffre.
Ce que ça change pour les décideurs
Choisir un prestataire qui traite des données sensibles (RH, financières, médicales, juridiques) sans MFA fort, c’est accepter un risque connu et documenté. Pas un risque théorique : un risque que les fuites récentes ont rendu concret et chiffrable.
Le MFA n’est plus à débattre. Ce qui reste à trancher : quel niveau, pour quels comptes, et si l’architecture actuelle le permet.
Pour les comptes standards : le TOTP coupe le credential stuffing. Pour les accès à fort enjeu (comptes administrateurs, accès aux données sensibles, professions réglementées) : FIDO2 est la seule réponse qui ferme les deux vecteurs. Pour les systèmes legacy qui ne supportent pas le MFA nativement : une couche IdP, pas une réécriture.
Vous voulez évaluer la solidité de votre architecture d’authentification ou mettre en place un IdP sur un périmètre legacy ? Parlons de votre contexte.