L'essentiel : le vol d'identifiants
- Vol contre stuffing : le vol est la manière dont les attaquants obtiennent des identifiants valides. Le stuffing est l'étape suivante. Signaux différents, piles de détection différentes.
- L'angle mort du MFA : le MFA standard n'arrête pas les quatre techniques dominantes : pages de phishing, proxys AiTM façon Evilginx, scripts tiers compromis, malwares infostealer.
- Votre propre page de connexion : votre surface la moins défendue est votre propre page de connexion. Un script tiers compromis lit le formulaire pendant que votre utilisateur saisit, et les contrôles côté serveur ne le voient jamais.
Peu de temps ? Découvrez la détection de prise de contrôle de compte de cside. Elle couvre tout ce qui suit en un seul déploiement.
Le vol d'identifiants n'est pas du credential stuffing (et la différence compte)
Imaginons qu'un éditeur antifraude vous dise qu'il « arrête les attaques sur les identifiants ». Demandez-lui laquelle des deux moitiés : le vol ou le stuffing. S'il ne sait pas répondre clairement, il vous vend de la limitation de débit déguisée en plateforme de menaces.
Le vol est le haut de l'entonnoir. Les attaquants collectent des identifiants valides. Le stuffing est le bas. Les attaquants testent ces identifiants sur des sites cibles. Une seule opération de vol alimente des milliers de campagnes de stuffing. Un seul identifiant volé peut être testé sur tous les marchands d'internet.
Les signaux de détection diffèrent :
- Le vol apparaît sur VOTRE site sous forme d'activité de script suspecte sur la page de connexion, ou d'exfiltration de données vers un domaine tiers inconnu.
- Le stuffing apparaît sur VOTRE site sous forme de tentatives de connexion en masse, de vélocité par IP et de schémas distribués lents et discrets.
La limitation de débit arrête le stuffing. Elle ne touche pas au vol. Si votre seule défense contre les attaques sur les identifiants est une limite de débit sur /api/login, vous attrapez la seconde moitié de l'attaque et laissez la première se dérouler sans obstacle.
Quatre techniques de vol de 2026 que votre MFA n'arrête pas
1. Les pages de phishing (toujours le vecteur numéro un)
Les attaquants enregistrent un domaine sosie (voir notre article sur les attaques homoglyphes et l'astuce des caractères cyrilliques), clonent le HTML de votre connexion et génèrent du trafic par SMS ou e-mail. L'utilisateur saisit son mot de passe sur une page identique à la vôtre. L'identifiant part chez l'attaquant.
Le MFA standard réduit la valeur du mot de passe volé, mais pas à zéro. Si l'utilisateur le réutilise ailleurs (environ 65 % le font, selon toutes les études sur la réutilisation), l'attaquant vient d'obtenir l'accès à sa messagerie, sa banque ou son parc SaaS.
2. Adversaire au milieu façon Evilginx (AiTM)
Evilginx est un framework de phishing open source qui exécute un proxy inverse entre la victime et la vraie page de connexion. La victime saisit son mot de passe. Evilginx le transmet au site réel. Le site réel renvoie la demande de MFA. La victime valide le MFA. Evilginx le transmet. Le site réel renvoie le cookie de session. Evilginx vole le cookie de session.
Cela met en échec le MFA par TOTP, OTP par SMS et notification push. Cela ne met pas en échec les passkeys ni les clés matérielles FIDO2, car celles-ci se lient cryptographiquement au domaine d'origine et refusent de s'authentifier sur un site passé par un proxy.
Si votre base d'utilisateurs n'est pas sur un MFA résistant au phishing en 2026, les attaques de classe Evilginx coûtent une misère aux attaquants. Le framework est open source, les modèles de phishing sont banalisés, et le gain est le contournement de toute implémentation de MFA autre que FIDO2.
3. Script tiers compromis sur votre propre page de connexion
C'est celle que la plupart des défenses manquent. Votre page de connexion est saine. Votre code serveur est sain. Vos certificats sont valides.
Mais votre page de connexion charge des scripts. Google Tag Manager. Un widget de chat. De l'analytique. Des tests A/B. N'importe lequel d'entre eux, ou n'importe laquelle de leurs dépendances transitives, peut être mis à jour par son propriétaire sans vous prévenir. Quand l'un est compromis, que ce soit par une attaque sur la chaîne d'approvisionnement comme Polyfill[.]io (plus de 490 000 sites touchés en 2024) ou par un changement de règle dans le gestionnaire de balises, le script compromis s'exécute désormais dans le même contexte JavaScript que votre formulaire de connexion.
Il peut lire les champs du formulaire. Il peut attacher un écouteur à l'événement d'envoi. Il peut transmettre les identifiants vers un domaine contrôlé par l'attaquant avant même que votre endpoint de connexion ne voie la requête.
Votre WAF ne voit pas cela. Vos journaux serveur ne voient pas cela. Votre SIEM ne voit pas cela. Le seul endroit où l'exfiltration est visible est la session du navigateur du visiteur, à l'instant où elle se produit.
4. Malware infostealer sur l'appareil de l'utilisateur
Les infostealers comme RedLine, Raccoon et LummaC2 récupèrent les mots de passe enregistrés dans les navigateurs, les cookies des stockages de session locaux et les jetons MFA des applications d'authentification. Une fois installés sur l'appareil d'une victime, ils tournent en continu et transmettent les identifiants collectés à l'infrastructure de l'attaquant.
Vous ne pouvez pas arrêter cette attaque depuis votre côté du fil. Ce que vous POUVEZ faire, c'est détecter l'usage en aval : une authentification qui réussit depuis une empreinte d'appareil ou une origine géographique incohérente avec l'historique du compte.
Le jeu de données que les attaquants utilisent réellement en 2026
RockYou2024 est le corpus de référence. Publié mi-2024, il contient environ 10 milliards de mots de passe uniques en clair. Un agrégat de toutes les compilations de fuites significatives qui l'ont précédé, dédupliqué et normalisé. Toute compilation antérieure (Collections #1 à #5, Pwned Passwords de Have I Been Pwned, les différentes fuites « COMB ») en est un sous-ensemble.
Les attaquants ne lancent pas 10 milliards d'identifiants contre votre connexion. Cela déclencherait n'importe quelle limite de débit. Ce qu'ils font, c'est :
- Filtrer les identifiants correspondant à votre domaine (via les métadonnées de la fuite source)
- Filtrer les identifiants créés au cours des 24 derniers mois (plus de chances d'être encore valides)
- Filtrer les mots de passe qui passent des heuristiques de robustesse basiques (les attaquants supposent que l'utilisateur a réutilisé un « vrai » mot de passe, pas
password123) - Tester le sous-ensemble filtré par lots lents et discrets depuis des IP résidentielles
Voilà pourquoi la réputation d'IP ne vous aide pas à attraper le credential stuffing moderne. L'IP est celle d'un FAI résidentiel. La vélocité par IP est de 2 à 3 tentatives par heure. Seule la corrélation entre comptes le détecte.
Ce qui détecte réellement le vol d'identifiants
Quatre sources de signal, par ordre de rentabilité.
1. Surveillance en session de votre page de connexion
La seule défense qui attrape la technique numéro trois (script tiers compromis) consiste à observer ce que les scripts lisent réellement dans le formulaire de connexion, au sein de la session du navigateur d'un utilisateur réel. C'est ce que fait la plateforme de sécurité côté client de cside. Un capteur first party observe les lectures du DOM, les accès aux champs de formulaire et l'activité réseau sortante dans chaque session réelle, puis signale tout script qui touche aux champs d'identifiants sans figurer sur la liste autorisée.
Vous ne pouvez pas construire cela vous-même en une seule fois. Il faut une observation continue sur chaque session réelle, car l'attaquant n'armera l'exfiltration que sur une fraction des visiteurs (géographie ciblée, navigateur ciblé, type de compte ciblé) pour échapper aux scanners de détection.
2. Intelligence d'appareil à la connexion
Au niveau de l'endpoint de connexion, calculez une empreinte d'appareil à partir des attributs du navigateur, de l'empreinte TLS ou JA et de la cadence comportementale. Comparez-la à l'historique d'appareils du compte. Un nouvel appareil depuis une nouvelle zone géographique qui tente de s'authentifier est un signal fort, qu'il vienne d'un AiTM façon Evilginx ou d'un vol récent par infostealer.
Notre introduction à l'intelligence d'appareil parcourt la pile de signaux. En résumé : plus de 40 attributs de navigateur combinés en un identifiant d'appareil stable qui survit à l'effacement des cookies et aux fenêtres privées.
3. Vérification Have I Been Pwned à la connexion (ou mieux, à l'inscription)
Have I Been Pwned publie une API de recherche par plage qui permet de vérifier si un mot de passe figure dans un corpus de fuites connu sans envoyer le mot de passe réel (via un préfixe SHA-1 en k-anonymat). Cela devrait être une étape de tout parcours de connexion au-dessus d'un certain score de risque.
Si un utilisateur s'authentifie avec un mot de passe présent dans RockYou2024, traitez cela comme une preuve prima facie de vol. Forcez une réinitialisation du mot de passe et passez à un MFA résistant au phishing à sa prochaine connexion.
4. Corrélation entre comptes
Le signal le plus fiable est qu'un même appareil, une même empreinte ou un même schéma comportemental tente de s'authentifier sur plusieurs comptes de votre plateforme dans une courte fenêtre. La limitation par compte passe à côté. La limitation par IP aussi, car les proxys résidentiels tournent toutes les 30 secondes. Seule la corrélation des signaux d'appareil le détecte.
Là où le MFA aide encore (et là où il n'aide pas)
Le MFA résistant au phishing (WebAuthn, clés matérielles FIDO2, passkeys) arrête réellement les cas de page de phishing et d'Evilginx. Si votre base d'utilisateurs n'y est pas passée d'ici fin 2026, vous entretenez un anachronisme.
Mais le MFA résistant au phishing n'aide pas contre :
- Un script tiers compromis sur votre propre page de connexion (le script lit le champ mot de passe quel que soit le type de MFA)
- Un malware infostealer sur l'appareil de l'utilisateur (le malware exfiltre la graine de la passkey ou le cookie de session après authentification)
- Les attaques par corrélation entre comptes (l'identifiant est déjà valide ; le MFA à la première connexion n'est pas le goulot d'étranglement)
La détection en couches (MFA plus surveillance en session plus intelligence d'appareil plus vérification HIBP) est ce qui referme les quatre brèches. Aucun contrôle isolé n'y parvient.
Ce que nous répondons à ceux qui demandent si cside est « encore un éditeur de MFA »
Nous ne le sommes pas. Le MFA, c'est ce qui se passe sur votre endpoint de connexion. cside, c'est ce qui se passe dans la session du navigateur, dans les sept secondes entre le moment où l'utilisateur saisit son mot de passe et celui où il valide. Nous voyons les scripts qui lisent le formulaire. Nous voyons les appels réseau sortants. Nous voyons les tentatives d'exfiltration qui n'atteignent jamais vos journaux serveur.
Si votre défense s'arrête à l'endpoint de connexion, vous ne voyez pas la technique numéro trois. C'est le cas d'environ 90 % des connexions e-commerce, fintech et SaaS en 2026. Corrigez-le et vous refermerez la plus grande brèche négligée de la chaîne d'attaque sur les identifiants.
Lectures associées
- Credential stuffing : comment le détecter et l'arrêter à la connexion
- Qu'est-ce que le fingerprinting d'appareil : le guide définitif 2026
- Prévention de la fraude par prise de contrôle de compte : le guide complet 2026
- Comment Polyfill[.]io a compromis 490 000 sites (attaque sur la chaîne d'approvisionnement du navigateur)
- Attaques homoglyphes : le problème аpple.com
