Have I Been Pwned : notre avis, et ce que racontent ses 1
041 fuites

Vous tapez votre adresse e-mail dans le champ, vous cliquez, et le bandeau vire au rouge : "Oh no, pwned!". En dessous, une liste de services, dont une plateforme dont vous aviez oublié jusqu'au nom. Première réaction légitime : est-ce que ce site est seulement sérieux ? Et la question suivante, celle que tout le monde se pose tout bas : si je lui donne mon mot de passe pour vérifier, est-ce que je ne suis pas en train de l'offrir à quelqu'un ?

Have I Been Pwned (HIBP) est l'outil de référence pour savoir si vos identifiants traînent dans une fuite connue. Plutôt que de donner un avis de principe, on a téléchargé son catalogue entier le 7 octobre 2026, soit 1 041 fuites, et on l'a passé au crible : ce qui fuite, à quelle vitesse ça arrive dans le catalogue, sous quelle forme les mots de passe y sont décrits. On a aussi interrogé sa base de mots de passe 6 234 fois pour une autre étude, ce qui nous a permis de vérifier de près le mécanisme de confidentialité. Le service mérite sa réputation ; il a aussi un retard structurel que peu de gens mesurent.

Have I Been Pwned, c'est quoi exactement

HIBP est un moteur de recherche de fuites de données, lancé en 2013 par Troy Hunt, un chercheur en sécurité australien. Quand la base d'un service se retrouve dans la nature (piratage, mauvaise configuration, revente sur un forum), Hunt la récupère, la vérifie, la déduplique, puis l'indexe. Vous entrez votre adresse, et le site vous dit dans quelles fuites elle apparaît. Deux recherches distinctes sont proposées :

• Par adresse e-mail : dans quelles fuites votre adresse a été vue, et quelles données sont parties avec (mot de passe, date de naissance, adresse IP...).
• Par mot de passe (le service Pwned Passwords) : ce mot de passe précis figure-t-il dans un corpus de fuites, et combien de fois. C'est ici que se pose la question de confiance.

La mesure : tout le catalogue, une photo du 7 octobre 2026

Le catalogue est public : l'endpoint /api/v3/breaches renvoie, sans clé d'API, une fiche par fuite avec sa date, sa date d'ajout, le nombre de comptes, les classes de données exposées, une description en texte libre et une série de drapeaux (vérifiée, fabriquée, liste de spam, journaux d'infostealer...). On a récupéré les 1 041 fiches en une requête, conservé la réponse brute avec son empreinte, puis tout calculé par script à partir de ce fichier. Une contre-expertise a ensuite recompté les principaux chiffres de façon indépendante et corrigé plusieurs libellés trompeurs, intégrés dans ce qui suit.

Trois limites cadrent la lecture. Le catalogue n'est pas l'univers des fuites : il dépend de ce que HIBP reçoit et parvient à vérifier. Le format des mots de passe est lu dans la description rédigée par HIBP, pas vérifié sur les données. Et les dates de fuite sont parfois approximatives : 178 des 1 041 tombent pile un 1^er du mois, signe d'une date estimée au mois ou à l'année.

Une fuite entre au catalogue 4,6 mois après les faits, en médiane

Pour chaque fuite d'organisation, on a calculé l'écart entre la date des faits et la date d'ajout au catalogue. On écarte ici les compilations, listes de spam et journaux d'infostealers, dont la "date de fuite" est en réalité une date d'assemblage. Restent 994 fuites, et une médiane de 141,5 jours, soit 4,6 mois.

La médiane cache une distribution en deux bosses. D'un côté, 30,5 % des fuites entrent au catalogue en moins de 30 jours : une base publiée sur un forum, transmise vite, vérifiée vite. De l'autre, 35,5 % y entrent plus d'un an après les faits, et une sur dix près de quatre ans après. Ce sont les bases qui ont circulé longtemps en privé, revendues de main en main, avant de finir par atterrir chez quelqu'un qui les transmet. Pendant tout ce temps, elles servaient déjà.

La conséquence est directe pour qui se fie à un écran vert. Un "Good news, no pwnage found" vous dit que votre adresse n'est dans aucune fuite connue de HIBP à ce jour. Historiquement, parmi les fuites qui finissent par y entrer, une fuite vieille de moins de 4,6 mois avait au moins une chance sur deux de ne pas encore y figurer.

Ce qui fuite : l'adresse toujours, le mot de passe deux fois sur trois

Chaque fiche liste les classes de données exposées. L'adresse e-mail est présente dans 1 034 fuites sur 1 041, ce qui n'étonne pas puisque c'est la clé de recherche du service. Le mot de passe, sous une forme ou une autre, dans 674, soit 64,7 %. Viennent ensuite les noms (560), les noms d'utilisateur (485), les adresses IP (387), les numéros de téléphone (377), les adresses postales (303) et les dates de naissance (286). Une fuite expose en médiane cinq classes de données différentes, et le catalogue en compte 163 au total.

Le volume, lui, se lit avec précaution. La somme des comptes de toutes les fiches atteint 17,8 milliards, mais c'est un cumul d'enregistrements, pas de personnes : une même adresse peut figurer dans des dizaines de fuites, et 7,0 milliards viennent de compilations qui recyclent d'autres bases. La fuite médiane, elle, compte un peu moins d'un million de comptes (995 274).

Le format des mots de passe : 57,5 % des fuites citent un format faible

La question qui intéresse un développeur : quand une base fuite avec ses mots de passe, sous quelle forme étaient-ils ? On a lu la description de chacune des 644 fuites d'organisations qui exposent des mots de passe, et retenu le format le plus faible qui y est cité. Le résultat se lit comme "au moins une partie des mots de passe était décrite sous cette forme", pas comme un audit du stockage.

En additionnant le clair, le MD5 et le SHA-1, on arrive à 370 fuites sur 644, soit 57,5 %, dont 13,7 % avec des mots de passe décrits en clair. Les formats conçus pour résister au cassage, bcrypt et les fonctions de dérivation lentes, ne pèsent que 18,6 %. En ne gardant que les fuites vérifiées, la part faible reste à 56,5 % : le résultat ne tient pas à quelques entrées douteuses.

Un MD5 ou un SHA-1 non salé se casse vite pour tout mot de passe humain, ce qui explique comment ces bases finissent en couples e-mail et mot de passe en clair dans les listes de credential stuffing. C'est aussi un grief récurrent des sanctions de la CNIL, que nous détaillons dans l'article sur le mot de passe compromis.

Et la France ? En retenant les domaines en .fr et les fiches qui qualifient explicitement l'organisation de française, on compte au moins 24 fuites, dont 11 sur un domaine en .fr et 7 qui exposent des mots de passe. C'est un plancher : la règle écarte des services français connus dont la fiche ne dit pas qu'ils sont français, et les ajouter ferait passer le compte à 28. On ne publie pas de total de comptes, il dépendrait entièrement de ces exclusions.

Taper son mot de passe sur HIBP : dangereux ?

C'est la crainte, et elle est saine. Comment un service peut-il vous dire "ce mot de passe a fuité des millions de fois" sans jamais le recevoir ? La réponse tient en un mot : k-anonymity. Votre navigateur calcule le hash SHA-1 du mot de passe en local, puis n'envoie que les cinq premiers caractères de cette empreinte. Le serveur renvoie tous les hachages du corpus qui commencent par ces cinq caractères, et c'est votre navigateur qui, en local, cherche si votre empreinte complète figure dans le lot.

# empreinte SHA-1 de "password"
echo -n password | sha1sum
# 5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8

# on n'envoie QUE les 5 premiers caractères ; Add-Padding brouille la taille de la réponse
curl -s -H 'Add-Padding: true' https://api.pwnedpasswords.com/range/5BAA6 \
  | grep -i 1E4C9B93F3F0682250B6CF8331B7EE68FD8
# 1E4C9B93F3F0682250B6CF8331B7EE68FD8:<nombre de fois vu dans les fuites>

Le serveur a vu passer 5BAA6, rien de plus. L'en-tête Add-Padding: true ajoute en plus des lignes factices au compteur nul, pour qu'un observateur du réseau ne puisse pas deviner le préfixe à la taille de la réponse. Quand on a interrogé l'API pour notre test de mots de passe, c'est le seul piège d'implémentation qu'on a dû traiter : une ligne de remplissage a un compteur à zéro, et il ne faut surtout pas la compter comme un résultat. Un recomptage indépendant des 6 254 compteurs, refait depuis les réponses brutes, a confirmé qu'aucune ne l'avait été.

Notre avis sur Have I Been Pwned : fiable, mais en retard par construction

Pour ce qu'il fait, on le recommande sans réserve. Le fonctionnement est documenté, l'API est ouverte, la vérification des mots de passe est conçue pour ne jamais exiger le secret, et le catalogue est tenu : 999 fiches sur 1 041 sont marquées vérifiées, trois seulement comme fabriquées. Des gestionnaires de mots de passe et Mozilla Monitor s'appuient sur ses données pour leurs propres alertes.

Ses angles morts ne sont pas des défauts, c'est le contrat de l'outil, mais il faut les connaître :

• Il ne voit que les fuites qui lui sont transmises. Une base revendue en privé n'y est pas, et notre mesure montre que même quand elle finit par y arriver, c'est plus d'un an après les faits dans 35 % des cas.
• C'est une photo, pas une surveillance. Vous cherchez aujourd'hui, tout est vert ; une fuite est ajoutée demain, vous ne le saurez que si vous êtes abonné aux notifications.
• Le mot de passe est vérifié "dans l'absolu". Pwned Passwords dit qu'une chaîne a déjà fuité quelque part, pas qu'elle est associée à votre compte. À l'inverse, un mot de passe humain absent de la base n'est pas pour autant solide : un générateur qui produit les mêmes motifs que vous le trouvera.
• La granularité reste l'adresse. La recherche par domaine (pour un propriétaire vérifié) liste des adresses touchées ; elle ne corrèle pas ces fuites avec le reste de votre exposition.

Pour comprendre par où les identifiants s'échappent en amont, notre article sur les fuites de secrets, clés d'API, tokens et credentials exposés détaille les mécaniques que HIBP, lui, ne regarde pas.

Les alternatives à Have I Been Pwned

La plupart des "alternatives" grand public s'appuient en réalité sur les données de HIBP. Mozilla Monitor (ex-Firefox Monitor) utilise son corpus de fuites : la question de sa fiabilité revient à celle qu'on vient de traiter, et il hérite du même délai. Les gestionnaires de mots de passe (1Password, Bitwarden) appliquent la vérification k-anonymity à votre coffre, ce qui reste la meilleure façon d'utiliser Pwned Passwords au quotidien. Les moteurs payants (DeHashed, Snusbase et consorts) indexent parfois des données que HIBP n'expose pas, mots de passe en clair compris : des outils d'investigation puissants, orientés OSINT offensif, avec les zones grises éthiques et légales qui vont avec.

HIBP pour un particulier, et pour une entreprise ?

Pour un individu, HIBP plus un gestionnaire de mots de passe couvrent l'essentiel : on repère où on a fuité, on change les mots de passe concernés, on active la double authentification, on s'abonne aux alertes.

Pour une organisation, le problème change de nature. Une boîte mail devient un annuaire entier, plus les accès des prestataires et les clés de service oubliées dans un dépôt. Un salarié qui réutilise sur son compte pro un mot de passe déjà fuité ailleurs offre un accès initial tout trouvé, et le retard médian de 4,6 mois du catalogue joue contre vous : c'est précisément la période où une base fraîche a le plus de valeur pour un attaquant.

C'est le rôle d'un module Leaks & Secrets au sein d'une démarche d'External Attack Surface Management : la vérification tourne en fond sur les identifiants et secrets liés à votre organisation, rattachés à leurs actifs. Là où HIBP répond à "est-ce que mon adresse a fuité ?", l'EASM répond à "qu'est-ce qui, sur tout mon périmètre, est exploitable maintenant ?".

À retenir

• Have I Been Pwned est fiable : 999 de ses 1 041 fuites sont vérifiées, et tester un mot de passe n'expose rien grâce à la k-anonymity (cinq caractères d'empreinte, jamais le mot de passe).
• Il est en retard par construction. Une fuite y entre en médiane 4,6 mois après les faits, et 35 % plus d'un an après. Un écran vert ne dit rien d'une fuite récente.
• Le mot de passe fuite deux fois sur trois (674 fuites sur 1 041), et quand il fuite, 57,5 % des fuites d'organisations le décrivent au moins en partie en clair, MD5 ou SHA-1.
• Les volumes affichés sont des enregistrements : 17,8 milliards cumulés, doublons et compilations compris, pas 17,8 milliards de personnes.
• À l'échelle d'une entreprise, la recherche ponctuelle ne suffit plus : il faut une surveillance continue et corrélée des identifiants et secrets sur tout le périmètre.

Reste la question qui dépasse la simple adresse : qu'est-ce qui fuite sur tout le périmètre de votre organisation ? Notre module Leaks & Secrets est bâti pour y répondre. Et si HIBP suffit à votre besoin, gardez HIBP : c'est un excellent service. Un doute, un cas particulier ? La page contact vous met en rapport avec un pentester.

Questions fréquentes