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 : 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 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.