Introduction
Dans un monde où chaque formulaire en ligne laisse une empreinte, savoir si des identifiants ont fuité n’est plus un luxe, c’est une hygiène de base. Have I Been Pwned (HIBP) s’est imposé comme le réflexe rapide pour vérifier une exposition et agir avant que le pire n’arrive. Né fin 2013, le service imaginé par Troy Hunt s’est taillé une réputation solide : une plateforme simple, rapide et conçue pour la confiance. L’objectif est limpide : transformer des données techniques (des fuites parfois obscures) en signal clair et actionnable pour toute personne ou toute organisation.
D’où vient HIBP et à quoi sert-il ?
HIBP part d’un constat simple : lors de violations massives, peu d’utilisateurs sont correctement informés. Résultat : les mêmes identifiants circulent et sont testés ailleurs (credential stuffing), avec à la clé des compromissions en chaîne. HIBP répond à ce vide opérationnel en offrant un point de vérification universel : saisir une adresse e-mail et savoir immédiatement si elle figure dans une fuite connue. En cas d’exposition, la page de résultat décrit les incidents, le type de données touchées et la chronologie, de quoi agir sans tergiverser : changer de mot de passe, activer la double authentification, révoquer des sessions, etc.
L’ambition ne s’arrête pas là. HIBP propose aussi Pwned Passwords, une base de mots de passe déjà compromis, à consulter en toute confidentialité pour éviter de réutiliser des secrets “brûlés”. Cette brique est devenue un standard d’intégration dans les navigateurs, gestionnaires de mots de passe et systèmes d’authentification.
Comment HIBP collecte et structure les données
HIBP agrège des fuites publiquement documentées ou partagées par la communauté sécurité. Le service normalise chaque incident : nom de la fuite, date, volume, types de données exposées. L’enjeu n’est pas d’accumuler “toutes” les données du monde, mais d’alimenter une base actionable qui sert un diagnostic rapide et fiable.
Au fil des années, HIBP a étendu ses sources et collaboré avec des acteurs institutionnels. Cette ouverture encadrée a renforcé la pertinence de la base, tout en conservant deux principes cardinaux : transparence et minimisation des données. L’architecture sépare clairement les adresses e-mail, les métadonnées d’incident et la base Pwned Passwords (stockée sous forme de hachages, indépendamment de toute identité).
Le partenariat avec les forces de l’ordre : pourquoi c’est un tournant
Un jalon fort a été la collaboration avec le FBI autour de Pwned Passwords. Concrètement, les mots de passe compromis découverts dans des enquêtes (botnets, opérations contre des groupes criminels, etc.) sont alimentés directement dans le référentiel. Cette relation change l’échelle : HIBP ne se contente plus de compiler ce qui est déjà largement diffusé, il intègre des jeux de données avant leur large circulation, ce qui réduit la fenêtre d’exploitation pour les attaquants.
Autre effet collatéral vertueux : cette coopération légitime HIBP comme infrastructure d’intérêt public. Le projet a par ailleurs ouvert le code de Pwned Passwords dans la .NET Foundation, un choix qui facilite l’audit indépendant et assure la pérennité au-delà d’un seul individu.
Confidentialité : le modèle de $k$-anonymat expliqué simplement
Vérifier si un mot de passe a fuité sans le dévoiler : c’est le paradoxe que Pwned Passwords résout via le $k$-anonymat.
Le principe en 3 étapes :
- Hachage local : le mot de passe est transformé en SHA-1 sur l’appareil (donc rien en clair ne quitte la machine).
- Requête par préfixe : seul le préfixe de 5 caractères du hachage est envoyé au service.
- Comparaison locale : le serveur renvoie tous les suffixes correspondant à ce préfixe ; la correspondance finale se fait côté client.
Ce mécanisme introduit une ambiguïté volontaire : le serveur sait que “quelque chose” commençant par ce préfixe est recherché, sans pouvoir l’identifier. HIBP propose en plus la mise à disposition hors-ligne des corpus (hashes SHA-1 et NTLM) pour les environnements qui préfèrent opérer sans dépendance réseau ou en réseau cloisonné. Résultat : des milliards de requêtes par mois, tout en préservant la vie privée des utilisateurs finaux et des organisations intégratrices.
Services principaux et garanties de confiance
Vérification d’adresse e-mail
- But : savoir si une adresse apparaît dans une ou plusieurs fuites.
- Sortie : message clair, liste des incidents, type de données concernées, contexte temporel.
- Garde-fous : pas de recherche massive publique ; la fonctionnalité Domain Search exige une preuve de contrôle du domaine pour délivrer des listes.
Pwned Passwords
- But : empêcher l’usage de mots de passe déjà exposés.
- Technique : $k$-anonymat avec requête par préfixe (5 caractères), corpus disponibles en SHA-1 et NTLM, option de téléchargement intégral pour vérifications hors-ligne.
- Gains : blocage préventif dès la création ou la rotation de mot de passe, sans fuite d’information chez le prestataire.
Notifications “Notify Me”
- But : alerter automatiquement si une adresse réapparaît dans une nouvelle fuite.
- Approche : inscription volontaire (opt-in), séparation stricte entre identité et vérification.
UI/UX : la simplicité comme réducteur de stress
HIBP cultive un design minimaliste : un champ, un bouton, un verdict. Ce dépouillement n’est pas cosmétique : face à une information anxiogène, chaque seconde compte. Une interface claire réduit la charge cognitive et oriente immédiatement vers l’action. Même logique côté feedback visuel : vert rassurant quand rien n’est détecté, rouge d’alerte en cas d’exposition, avec pédagogie sur la nature des données et les gestes à adopter.
En 2025, le service a modernisé son identité et son site, tout en ouvrant des briques UX au public : un “soft-launch” assumé, des retours intégrés, et un site intégralement repensé pour accélérer les parcours et clarifier les fonctionnalités avancées. L’UX n’est pas accessoire : c’est un facteur de taux d’adoption et donc d’impact réel sur la sécurité.
L’API HIBP : colonne vertébrale des intégrations
HIBP expose une API v3 mature, devenue la brique standard pour orchestrer des contrôles à l’inscription, à la montée de privilège ou à la rotation des secrets :
- Endpoints e-mail : vérifier l’implication d’une adresse dans des incidents connus.
- Pwned Passwords : API de plage (range) exploitant le $k$-anonymat, privilégiée pour sa rapidité et son anonymat de requête.
- Opérations hors-ligne : mise à disposition d’outils officiels pour pré-rapatrier toutes les réponses par préfixes et interroger localement.
Cas d’usage fréquents :
- Gestionnaires de mots de passe : filtrer dès la proposition d’un nouveau secret.
- Navigateurs : avertir en temps réel lors de la saisie.
- SSO et IAM : politique de conformité (refus des mots de passe compromis, contrôle périodique).
- Secteur public : vérifications en volume, déclenchées par événements, avec journaux et seuils.
Alternatives et positionnement
Firefox Monitor
Avantage : intégration pratique dans l’écosystème Mozilla, notifications et ergonomie soignée. Particularité : la donnée de référence reste largement celle d’HIBP. Pour un utilisateur de Firefox, l’expérience est fluide ; la fiabilité dépend toutefois de la qualité de la base HIBP sous-jacente.
DeHashed (et outils d’investigation)
Positionné côté enquête et recherche granulaire, y compris des sources moins accessibles. Utile pour les équipes sécurité qui mènent des analyses approfondies, avec des fonctionnalités payantes et des jeux de données plus “profonds”. Pour un usage quotidien grand public ou pour du contrôle préventif intégré, HIBP reste la base la plus accessible et la mieux industrialisée.
Pourquoi HIBP est devenu une référence
- Éthique et transparence : architecture pensée pour minimiser les données et éviter toute réidentification inutile.
- Innovation utile : $k$-anonymat opérationnel, à grande échelle, avec options API et hors-ligne.
- Adossement institutionnel : apports réguliers de renseignements utiles (FBI, forces de l’ordre) qui réduisent la surface de risque.
- Expérience immédiate : un test en quelques secondes, une interprétation simple, un plan d’action clair.
Recommandations pratiques
- Activer les notifications : rester informé évite de découvrir une fuite trop tard.
- Bloquer les mots de passe compromis : côté entreprise, intégrer l’API Pwned Passwords dans la politique IAM.
- Désilotter : lier les alertes HIBP à des playbooks de réponse (forcer la rotation, invalider des sessions, déclencher MFA).
- Éduquer sans dramatiser : former les équipes à lire un rapport HIBP et à en déduire l’action adéquate.
- Surveiller les domaines : pour les organisations, Domain Search avec vérification de propriété est indispensable.
Conclusion
HIBP a réussi ce que beaucoup d’initiatives de cybersécurité peinent à concilier : rigueur technique, simplicité d’usage et confiance. Le service remplit un rôle d’infrastructure : thermostat collectif du risque d’identité, branché sur des flux toujours plus riches, ouvert à l’audit, pensé pour durer.
La combinaison $k$-anonymat + API + partenariats institutionnels en fait un outil préventif d’une rare efficacité. Qu’il s’agisse de vérifier une boîte e-mail personnelle, d’imposer une politique de mots de passe saine ou d’automatiser des contrôles à l’échelle d’un SI, HIBP fournit le langage commun entre utilisateurs, développeurs et équipes sécurité. Et c’est précisément ce qui en fait la référence pour défendre les identités numériques, sans barrière à l’entrée.
FAQ
HIBP conserve-t-il mon e-mail ? Le service ne publie pas d’adresses et limite la recherche publique à une adresse à la fois. Pour des listes liées à un domaine, une preuve de propriété est exigée.
Puis-je vérifier un mot de passe en clair ? Inutile, et surtout déconseillé. La vérification passe par un hachage local et l’envoi d’un simple préfixe ; la comparaison finale se fait sur l’appareil.
L’API est-elle utilisable en entreprise ? Oui. Endpoints e-mail et Pwned Passwords (range API) sont conçus pour l’intégration. Des corpus hors-ligne existent pour les environnements isolés.
Pourquoi parler de SHA-1 ? Il s’agit ici de hachage de vérification, pas de stockage de mots de passe utilisateurs. L’objectif est la compatibilité et la vitesse pour matcher des fuites historiques à grande échelle.
HIBP remplace-t-il un SOC ou un EDR ? Non. HIBP est un capteur d’exposition d’identifiants. Il s’intègre en amont (politiques) et en aval (réponse), mais ne remplace pas la détection d’intrusion.