# Ce qui arrive vraiment quand votre mot de passe fuite

> Une fuite ne se termine pas le jour où la presse en parle : elle commence là. On la casse, on la croise avec d'autres listes, on la revend — et tout cela ne tient qu'à une chose : nous réutilisons.

2026-04-16 · David Carrero · password.es
Original: https://password.es/fr/blog/ce-qui-arrive-vraiment-quand-votre-mot-de-passe-fuite/

---

Quand on apprend que son mot de passe a fuité, on se le représente comme un
accident isolé : un service a eu une mauvaise journée, c'est passé dans la presse,
vous l'avez changé, fin de l'histoire. **Ce n'est pas la fin.** Le jour de la fuite
ne clôt rien du tout : c'est le premier jour d'une chaîne de montage qui va durer
des années, et dans laquelle vous n'apparaîtrez jamais sous votre nom. Elle mérite
d'être racontée en entier, parce que presque personne ne la voit.

## Étape un : quelqu'un sort la base de données

Le début n'a rien de spectaculaire. Quelqu'un trouve une injection SQL, une
sauvegarde laissée ouverte, un panneau d'administration avec les identifiants par
défaut. Et il repart avec une table.

Cette table, avec un peu de chance, contient votre adresse e-mail et un hash de
votre mot de passe. Avec moins de chance, elle contient votre adresse e-mail et
votre mot de passe. En clair. Exactement tel que vous l'avez tapé.

## 2009 : trente-deux millions de mots de passe en clair

En décembre 2009, une entreprise de widgets pour réseaux sociaux nommée **RockYou**
subit une injection SQL. Environ **32 millions de mots de passe** sont partis, et
il n'y avait aucun hash à casser : ils étaient stockés en clair.

Un désastre pour RockYou, un cadeau pour tous les autres. Pour la première fois, il
existait un corpus énorme de mots de passe **réels**, écrits par des gens qui
ignoraient qu'on les lirait un jour. Pas une étude : la chose elle-même.

Le fichier est devenu `rockyou.txt`, et il reste le dictionnaire de référence avec
lequel on teste les attaques. Sa valeur ne tient pas au fait qu'il contienne votre
mot de passe : elle tient au fait qu'il contienne **la façon dont les gens
écrivent leurs mots de passe**. Un prénom et une année, le mot et le `123`, le `!`
à la fin. RockYou n'a pas fait fuiter 32 millions de secrets. Il a fait fuiter le
patron. Et un patron, ça ne périme pas.

## Étape deux : on casse ce qui se casse, sans aucune urgence

C'est ici que l'intuition se trompe. Quand quelqu'un essaie de deviner votre mot de
passe sur l'écran de connexion d'un service, le service le coupe : trois essais, un
CAPTCHA, un blocage. Face à un serveur, deviner est lent et bruyant.

Face à un fichier de hashs déjà posé sur son disque, il n'y a plus de serveur.
**Personne, en face, pour dire non.** On teste en local, avec des GPU, sans limite
d'essais et avec tout le temps du monde. Si le service a mal haché — algorithme
rapide, pas de sel — l'écart avec le texte en clair est une question de confort, pas
de sécurité.

Et on ne teste pas au hasard : d'abord `rockyou.txt`, puis les règles qui en
dérivent. Remplace le `a` par `@`. Ajoute une année à la fin. Chaque astuce qui vous
a paru futée est écrite depuis plus de dix ans dans un fichier de configuration.

De là sort une partie du dump convertie en mots de passe lisibles. Le reste — le
long, l'aléatoire, ce qui ne figure dans aucun dictionnaire — reste du bruit. C'est
la ligne que trace le [vérificateur](/fr/verificateur/) : il ne vous fait pas la
morale, il vous dit de quel côté vous tombez.

## Étape trois : on croise, et c'est là que vous valez de l'argent

Un dump isolé ne vaut pas grand-chose. Ce qui a de la valeur, c'est
l'**agrégation** : prendre dix fuites de sites différents, les croiser par adresse
e-mail et ne garder que les paires `e-mail:mot de passe` déjà en clair. Le résultat
s'appelle une *combolist*, et ce n'est plus la base de données de personne. C'est
une liste de personnes.

## 2013 : l'inventaire sort au grand jour

En décembre 2013, **Troy Hunt** lance **Have I Been Pwned** : une base publique des
adresses e-mail apparues dans des fuites, pour que n'importe qui puisse demander
s'il est dedans. L'idée de fond est simple et dérangeante : **si les attaquants ont
déjà l'inventaire, le refuser aux victimes ne protège personne**. Des années plus
tard est arrivé *Pwned Passwords*, qui fait la même chose avec les mots de passe et
permet de les consulter sans les envoyer : on transmet un fragment du hash et le
serveur renvoie un lot de candidats, sans savoir lequel était le vôtre.

## 2017 : le NIST cesse de réclamer des symboles et commence à réclamer des listes

En publiant le **SP 800-63B**, le NIST a jeté par-dessus bord presque toute
l'orthodoxie des formulaires et l'a remplacée par une exigence que peu de gens
attendaient : au moment où l'on fixe un mot de passe, le système doit **le comparer
à une liste de valeurs compromises connues** et le refuser s'il y figure.

C'est un changement de théorie, pas de détail. La question n'est plus de savoir si
votre mot de passe *a l'air* solide, mais s'il est **déjà publié**. C'est pour ça
que le [générateur](/fr/) fait la seule chose raisonnable : le tirer d'un endroit
où il n'a jamais été.

## 2019 : la fuite qui était déjà un réchauffé d'autres fuites

En janvier 2019 circule un paquet devenu célèbre sous le nom de **Collection #1**.
Hunt l'a analysé et a compté ce qu'il y avait dedans : environ **773 millions
d'adresses e-mail uniques** et environ **21 millions de mots de passe uniques** en
clair, agrégés à partir de milliers de sources.

L'important n'était pas la taille. C'était **la provenance** : pour l'essentiel, un
réchauffé de fuites antérieures, déjà cassées et remises dans un format pratique —
même si Hunt y a aussi trouvé du matériel qu'il n'avait pas encore répertorié. Le
produit n'était pas l'intrusion. C'était l'inventaire. Et un inventaire pareil n'a
qu'un seul usage.

## Credential stuffing : ce n'est pas vous qu'on attaque

**Personne ne vous attaque.** C'est la partie difficile à admettre.

Personne ne s'assoit pour réfléchir à votre compte. Quelqu'un prend une combolist de
plusieurs centaines de millions de lignes, la passe dans un outil qui les teste
contre le formulaire de connexion d'une banque ou d'une messagerie, répartit les
tentatives sur de nombreuses adresses IP pour ne pas déclencher les blocages, et
attend. L'immense majorité échoue. Peu importe : elles ne coûtent presque rien.

C'est ça, le *credential stuffing*, et ce n'est pas deviner. C'est **vérifier**. Le
mot de passe, ils l'ont déjà ; la seule chose qu'ils découvrent, c'est où d'autre
vous l'avez mis.

Votre mot de passe de ce forum n'avait aucune importance. Le forum non plus. Ce qui
compte, c'est que la même suite de caractères ouvre votre boîte mail, et que votre
boîte mail ouvre tout le reste via « j'ai oublié mon mot de passe ». **Le péché
originel n'est pas qu'il était faible : c'est qu'il était le même.** Un mot de passe
de trente caractères, aléatoire et parfait, réutilisé sur deux sites, vaut exactement
le pire des deux. Et vous ne contrôlez pas la façon dont le pire des deux le hache.

## Ce qu'il faut en tirer

- **Changer le mot de passe qui a fuité ne suffit pas si vous l'avez répété.**
  L'urgence, ce n'est pas le site qui est passé aux informations. Ce sont les autres.
- **Un mot de passe par site, et qu'il vous soit égal de l'oublier.** Si vous pouvez
  vous souvenir de tous vos mots de passe, c'est que vous en avez très peu ou qu'ils
  sont très mauvais.
- **Le second facteur casse la chaîne.** Le *credential stuffing* teste
  `e-mail:mot de passe`. Si ça ne suffit pas pour entrer, l'inventaire ne vaut plus
  rien.

Votre mot de passe qui a fuité n'est pas entre les mains d'un ennemi. Il est sur une
ligne d'un fichier, parmi des centaines de millions d'autres, en attendant que
quelqu'un trouve rentable de l'essayer sur un site de plus. Et la seule chose qui
décide si ça marchera, c'est vous qui l'avez décidée il y a des années, en écrivant
le même mot une deuxième fois.

---

*Sources : la fuite de RockYou (décembre 2009) et l'usage ultérieur de `rockyou.txt`
comme dictionnaire d'attaque · Have I Been Pwned et Pwned Passwords, de Troy Hunt ·
NIST SP 800-63B, sur la vérification des mots de passe face à des listes de valeurs
compromises · l'analyse de Troy Hunt sur Collection #1 (janvier 2019) et les chiffres
qu'il a publiés · définition du credential stuffing par l'OWASP.*