Lancement de Have I Been Pwned 2.0

• Le rebranding de HIBP, préparé de longue date, est désormais déployé en production, avec une reconstruction complète du site et une refonte fonctionnelle de presque toutes les pages
• La recherche principale améliore l’expérience des résultats, mais le site web supprime la recherche par username et numéro de téléphone, tout en conservant la compatibilité de l’API existante
• Les nouvelles pages dédiées à chaque fuite rendent les résultats de recherche moins complexes et déplacent sur un écran séparé les consignes d’action concrètes à suivre après un incident
• Les fonctions nécessitant une vérification d’accès à l’adresse e-mail sont regroupées dans un tableau de bord basé sur la connexion, et la recherche de domaine fonctionne plus vite grâce à une API JSON et au filtrage côté client
• La pile technique s’articule autour d’Azure, Cloudflare, .NET 9.0, Bootstrap et TypeScript, et n’utilise plus que Cloudflare Turnstile, sans Google reCAPTCHA

---

Nouveau site web et nouvelle expérience de recherche

• Le nouveau site Have I Been Pwned est en ligne
  • Le premier commit public lié au rebranding dans le dépôt a été effectué en février 2024
  • La nouvelle marque a fait l’objet d’un soft launch en mars 2025
  • Cette version inclut une reconstruction complète du site, des changements fonctionnels sur presque toutes les pages, de nouvelles fonctionnalités et l’ouverture d’une boutique de produits dérivés
• Le champ de recherche principal conserve la fonction emblématique de HIBP, mais change la manière d’afficher les résultats
  • Certains utilisateurs verront une réaction de félicitations et une animation de confetti
  • Lorsqu’une fuite est détectée, une réponse rouge plus sobre est affichée
  • Les résultats prennent la forme d’une timeline défilante en ordre chronologique inverse, avec un aperçu de chaque fuite
• La recherche sur le site ne prend plus en charge les username ni les numéros de téléphone
  • La recherche par username avait été ajoutée pour l’incident Snapchat de 2014
  • La recherche par numéro de téléphone avait été ajoutée pour l’incident Facebook de 2021
  • Ces deux types de données n’ont jamais été chargés en dehors de ces deux cas
  • Il est difficile d’identifier le propriétaire d’un username, et les numéros de téléphone sont compliqués à parser à cause des formats internationaux et des différences d’écriture
  • Les alertes par SMS coûtent beaucoup plus cher que les e-mails
  • Le fait d’autoriser ces entrées sur l’ancien site provoquait de la confusion et une charge de support du type « pourquoi mon numéro n’apparaît-il pas dans telle fuite ? »
  • L’API continue de les prendre en charge pour préserver la compatibilité, mais il est précisé qu’il ne faut pas s’attendre à de nouvelles données

Pages dédiées par fuite

• La nouvelle breach page sépare les détails de chaque fuite dans un écran dédié afin de réduire la complexité excessive des résultats de recherche principaux
  • Exemple : page de fuite Ashley Madison
  • Les informations existantes y sont présentées de manière plus conviviale
• Le principal changement de cette page consiste à guider plus concrètement les utilisateurs sur les actions à entreprendre après une fuite
  • L’accent est mis sur ce que doit faire une personne touchée
  • Cela inclut aussi une orientation vers des services partenaires comme un identity protection provider
• Il est prévu d’enrichir davantage les données sur les futures fuites et sur les informations propres à chaque utilisateur
  • Si le service concerné prend en charge la 2FA, cela sera indiqué explicitement au lieu d’un conseil générique
  • Les passkeys doivent aussi être ajoutées dans une section dédiée
  • Des échanges avec le NCSC britannique portent sur des guides localisés de fuite de données, avec affichage du logo du NCSC et de ressources associées pour les utilisateurs du Royaume-Uni

Tableau de bord unifié et recherche de domaine

• Les fonctionnalités nécessitant de vérifier l’accès à une adresse e-mail se sont multipliées au fil des années, au point d’être regroupées dans un tableau de bord central
  • Lors de l’affaire Ashley Madison en 2015, la notion de sensitive breach a été introduite, avec nécessité de vérification par réception d’e-mail
  • En 2019, une couche d’authentification a été ajoutée à l’API pour réduire les abus, avec vérification de l’e-mail avant l’achat d’une clé API
  • Ensuite se sont ajoutés le domain search dashboard, la gestion des abonnements payants et la consultation des stealer logs
• Le nouveau tableau de bord vérifie l’accès à l’adresse e-mail après une seule connexion, puis affiche les fonctions correspondantes
  • Il réunit à la fois des fonctions grand public et des fonctions orientées entreprise
  • Un support des passkeys est prévu afin de permettre à terme une connexion sans envoi d’e-mail
  • La possibilité d’inscrire l’adresse e-mail d’un membre de la famille aux alertes tout en recevant les notifications sur une autre adresse est donnée comme exemple de fonction qui s’intègre bien au tableau de bord
• La recherche de domaine bénéficie de nombreuses améliorations d’interface et de filtrage
  • La liste des domaines vérifiés est plus propre
  • Les résultats de recherche fournissent des résumés plus clairs
  • Des filtres par adresse e-mail et un filtre « latest breach uniquement » ont été ajoutés
• Le tableau de bord de recherche de domaine récupère du JSON depuis l’API et l’ensemble du tableau de bord fonctionne comme une application monopage
  • Le filtrage est effectué côté client sur l’ensemble du JSON de recherche de domaine
  • Des tests ont confirmé que cela fonctionne même avec des domaines contenant plus de 250 000 adresses e-mail compromises
  • Cela dit, pour un tel volume de données, il reste plus adapté de passer par l’API que de faire défiler les résultats dans le navigateur
• La vérification de propriété de domaine a elle aussi été entièrement réécrite
  • L’interface est devenue plus propre et plus simple
  • Les méthodes de vérification autres que l’e-mail doivent encore être rendues plus fluides

Documentation API et boutique de produits dérivés

• L’API elle-même ne change pas
  • Cette mise à jour n’introduit aucun breaking change
  • Les utilisateurs actuels de l’API ne rencontreront aucune rupture
• La documentation API n’a pas pu être migrée vers la nouvelle approche et conserve donc son format actuel
  • Des discussions ont eu lieu dans le dépôt GitHub UX rebuild sur la manière de documenter l’API, et le consensus général allait vers OpenAPI
  • Un travail a été mené avec Scalar, visible sur haveibeenpwned.com/scalar
  • Scalar fournit des exemples dans plusieurs langages ainsi qu’un runner de test dans le navigateur
  • Faute d’avoir pu finaliser cela dans le calendrier du grand lancement, l’ancienne documentation API a été conservée en l’alignant visuellement sur le nouveau site
  • Une bascule vers l’implémentation Scalar est prévue quand il y aura plus de temps
• La boutique HIBP est ouverte sur merch.haveibeenpwned.com
  • Elle est exploitée via Teespring
  • Tous les produits sont vendus au prix coûtant, sans bénéfice
  • C’est une initiative ludique pour la communauté
• Pour les stickers, les options de Teespring n’atteignant pas la qualité habituelle de Sticker Mule, l’ancienne boutique Sticker Mule reste utilisée
  • Les illustrations open source sont aussi fournies, afin de permettre une impression libre ailleurs

Pile technique et performances

• Le service d’origine continue de fonctionner sur Microsoft Azure
  • Le site web utilise App Service
  • La majeure partie de l’API repose sur des Functions serverless
  • Le service utilise SQL Azure Hyperscale, des queues, des blobs, des tables et d’autres fonctions du storage account
  • Le code est majoritairement en C#, avec .NET 9.0 et ASP.NET MVC sur .NET Core
• Cloudflare continue aussi de jouer un rôle majeur
  • Beaucoup de code s’exécute dans les Workers
  • Les données sont stockées dans R2 storage
  • Le WAF et les fonctions de caching sont utilisés
  • Pour l’anti-automation, seul Cloudflare Turnstile est utilisé, Google reCAPTCHA ayant été entièrement supprimé
• Le front-end utilise la génération récente de Bootstrap, SASS et TypeScript
  • Le CSS est écrit en SASS
  • Le JavaScript est écrit en TypeScript
• Les performances du site affichent aussi des améliorations mesurables
  • Selon les tests Pingdom, la taille des pages a été réduite de 28 %
  • Le nombre de requêtes a été réduit de 31 %
  • Les temps de chargement étant très variables, il n’est pas affirmé qu’il existe une différence majeure sur ce point
  • Il est souligné qu’au bout de 11 ans, parvenir encore à réduire de façon à deux chiffres la taille des pages et le nombre de requêtes reste notable
• Aucun élément assimilable à du tracking ou à une charge publicitaire n’a été ajouté
  • Les statistiques réelles de trafic reposent sur le trafic passant par les edge nodes de Cloudflare
  • Le placement produit de 1Password ne consiste qu’en texte et en images
  • Même les clics sortants ne sont pas suivis
  • Cela complique davantage les discussions de placement produit avec des sociétés de protection contre l’usurpation d’identité qui attendent des métriques de suivi intrusives

Usage de l’IA pendant le développement

• ChatGPT a été largement utilisé pendant la reconstruction, en particulier dans les tout derniers jours
  • Il a servi à trouver une icône adaptée au heading « Index » parmi les Bootstrap icons
  • L’usage consistait par exemple à identifier en une trentaine de secondes une icône pertinente parmi plus de 2 000
• L’IA a aussi été utilisée pour la vérification de la migration du site
  • Elle a servi à écrire un script PowerShell qui crawl haveibeenpwned.com et affiche les URL uniques
  • Elle a aussi servi à écrire un script vérifiant si les chemins détectés existent sur stage.haveibeenpwned.com
  • Elle a aidé à repérer le fichier security.txt manquant
  • Elle a également trouvé des éléments qui n’avaient jamais existé, d’où la nécessité de « trust, but verify »
• Elle a aussi été mise à contribution pour de petites tâches comme des conseils CSS, la configuration de règles Cloudflare ou des particularités d’une web app .NET Core
  • Le taux de réponses correctes est estimé à environ 90 %
  • L’auteur se montre très positif, au point d’affirmer que ne pas utiliser activement l’IA dans le développement logiciel serait une erreur

Lancement et problème Turnstile

• Le nouveau site a été déployé tôt dimanche matin, selon l’auteur
  • Presque tout s’est bien passé, et un ou deux petits glitches ont été rapidement corrigés puis redéployés
  • L’article n’a été publié que deux jours après la mise en ligne, afin de résoudre un maximum de problèmes au préalable
  • Entre-temps, plus de 12 nouvelles releases ont été déployées dans une logique d’itération rapide
• Même de petites modifications comme les conditions d’utilisation et la politique de confidentialité ont demandé beaucoup de temps
  • Il fallait refléter de petites mises à jour du traitement des données ainsi que de nouveaux services comme les stealer logs
  • Le travail avec les avocats a représenté plusieurs heures et plusieurs milliers de dollars
• Cloudflare Turnstile est une méthode d’anti-automation qui, à la différence de Google reCAPTCHA, n’envoie pas le trafic à Google
  • Elle peut être implémentée de manière totalement invisible
  • Dans le navigateur, le script Cloudflare crée un challenge, qui est soumis avec la requête HTTP puis vérifié côté serveur
  • HIBP l’utilisait déjà sous une forme ou une autre depuis 2023
• Dans les formulaires où le blocage des bots est important, comme ceux qui envoient des e-mails, en cas d’échec de Turnstile, un message invite l’utilisateur à réessayer ou à rafraîchir la page
  • Un second clic ou un rechargement de page suffisait souvent à résoudre le problème
  • Si cela ne suffit pas, il faudra envisager un widget Turnstile plus visible, demandant une interaction utilisateur
• Turnstile joue aussi un rôle important sur la page de recherche principale
  • La page envoie une requête asynchrone à un endpoint API avec le challenge token
  • Si le challenge échoue et que l’endpoint HIBP renvoie HTTP 401 avec Invalid Turnstile token, un fallback en full page post devait prendre le relais
  • Lors du lancement initial du nouveau site, ce fallback ne fonctionnait pas, mais cela a ensuite été corrigé
  • En full page post, un managed challenge de Cloudflare est affiché, plus intrusif mais plus fiable
• Selon les statistiques Cloudflare, environ 82 % des challenges émis sont résolus avec succès
  • Une part significative des 18 % non résolus peut correspondre à des bots effectivement bloqués comme prévu par Turnstile
  • La part de requêtes humaines réellement bloquées est probablement à un chiffre, et il faut continuer à chercher comment la réduire