Have I Been Pwned 2.0 veröffentlicht

• Das lange vorbereitete Rebranding von HIBP ist in den Live-Betrieb übergegangen; zugleich wurden ein kompletter Neuaufbau der Website und Funktionsüberarbeitungen auf fast allen Seiten veröffentlicht
• Die Hauptsuche verbessert die Ergebnisdarstellung, entfernt auf der Website jedoch die Suche nach username und phone number; die Kompatibilität der bestehenden API bleibt erhalten
• Neue Seiten pro Datenpanne machen die Suchergebnisse weniger komplex und lagern konkrete Handlungsempfehlungen für Nutzer nach einem Vorfall in eine separate Ansicht aus
• Funktionen, die eine Verifizierung des Zugriffs auf eine E-Mail-Adresse erfordern, wurden in einem Sign-In-basierten Dashboard gebündelt; die domain search arbeitet dank JSON-API und clientseitigem Filtering schneller
• Der Tech-Stack wurde auf Azure, Cloudflare, .NET 9.0, Bootstrap und TypeScript fokussiert; Google reCAPTCHA wurde entfernt, es kommt nur noch Cloudflare Turnstile zum Einsatz

---

Neue Website und Sucherlebnis

• Die neue Website von Have I Been Pwned ist online
  • Der erste Commit für das Rebranding im öffentlichen Repository erfolgte im Februar 2024
  • Die neue Marke wurde im März 2025 soft gelauncht
  • Dieses Release umfasst den kompletten Neuaufbau der Website, Funktionsänderungen auf nahezu allen Seiten, neue Funktionen und die Veröffentlichung eines Merch-Stores
• Das Hauptsuchfeld behält die Kernfunktion von HIBP bei, ändert aber die Darstellung der Ergebnisse
  • Einige Nutzer sehen eine Glückwunschreaktion und eine confetti-Animation
  • Wenn eine Datenpanne gefunden wird, erscheint eine ruhigere rote Antwort
  • Die Ergebnisse werden als scrollbare timeline in umgekehrt chronologischer Reihenfolge angezeigt, jeweils mit einer Zusammenfassung der betroffenen Datenpanne
• In der Website-Suche wurde die Unterstützung für username und phone number entfernt
  • Die Suche nach username wurde 2014 für den Snapchat incident eingeführt
  • Die Suche nach phone number wurde 2021 für den Facebook incident eingeführt
  • Diese beiden Datentypen wurden außer für diese zwei Fälle nie geladen
  • Ein username lässt sich schwer einem Eigentümer zuordnen, und phone numbers sind wegen internationaler Formate und unterschiedlicher Schreibweisen schwierig zu parsen
  • SMS-Benachrichtigungen sind erheblich teurer als E-Mails
  • Dass die alte Website diese Eingaben erlaubte, führte zu Verwirrung und Supportaufwand, etwa mit Fragen wie „Warum ist meine Nummer nicht in einer bestimmten Datenpanne enthalten?“
  • In der API bleiben sie aus Kompatibilitätsgründen weiter unterstützt, es wird aber ausdrücklich davor gewarnt, mit zusätzlichen Daten dafür zu rechnen

Eigene Seiten pro Datenpanne

• Die neue breach page lagert Detailinformationen zu jeder Datenpanne auf eine eigene Ansicht aus, um zu verhindern, dass die Hauptsuchergebnisse zu komplex werden
  • Ein Beispiel ist die Ashley Madison breach page
  • Bestehende Informationen werden benutzerfreundlicher dargestellt
• Die zentrale Änderung der Seite besteht darin, konkreter zu erklären, was Nutzer nach einer Datenpanne tun können
  • Der Fokus liegt darauf, was betroffene Nutzer unternehmen sollten
  • Dazu gehört auch die Ausrichtung auf Verknüpfungen mit Partnerdiensten wie identity protection provider
• Künftig sollen Daten zu Datenpannen und nutzerspezifische Daten weiter ausgebaut werden
  • Wenn der betreffende Dienst 2FA unterstützt, soll dies statt allgemeiner Hinweise konkret angezeigt werden
  • Auch passkey soll als eigener Abschnitt ergänzt werden
  • In Gesprächen mit dem britischen NCSC ging es um einen lokalisierten Leitfaden zu Datenlecks, der Nutzern in Großbritannien das NCSC-Logo und zugehörige Informationsressourcen zeigt

Integriertes Dashboard und Domain-Suche

• Da über die Jahre immer mehr Funktionen eine Bestätigung des Zugriffs auf eine E-Mail-Adresse erforderten, wurden sie in einem central dashboard zusammengeführt
  • Beim Ashley-Madison-Vorfall 2015 wurde das Konzept sensitive breach eingeführt, wodurch eine Bestätigung per E-Mail erforderlich wurde
  • 2019 wurde der API eine Authentifizierungsschicht hinzugefügt, um API-Missbrauch zu reduzieren; vor dem Kauf eines API key wurde eine E-Mail-Verifizierung verlangt
  • Später kamen domain search dashboard, Verwaltung kostenpflichtiger Abonnements und die Abfrage von stealer logs hinzu
• Das neue Dashboard verifiziert hinter einem einzigen Sign In den Zugriff auf die E-Mail-Adresse und zeigt anschließend die zugehörigen Funktionen an
  • Es enthält sowohl Funktionen für die breite Öffentlichkeit als auch geschäftsorientierte Funktionen
  • Künftig soll passkey-Unterstützung ergänzt werden, damit ein Login ohne E-Mail-Versand möglich ist
  • Als Beispiel für das Dashboard wird auch eine Funktion genannt, bei der E-Mail-Adressen von Familienmitgliedern für Benachrichtigungen registriert werden, die Benachrichtigungen aber an eine andere Adresse gehen
• Bei der domain search wurden viele Verbesserungen an Oberfläche und Filtering vorgenommen
  • Die Liste verifizierter Domains ist übersichtlicher
  • Suchergebnisse liefern klarere Zusammenfassungen
  • Filtering nach E-Mail-Adresse und ein Filter „nur latest breach anzeigen“ wurden hinzugefügt
• Das Dashboard für die Domain-Suche erhält JSON aus der API, und das gesamte Dashboard funktioniert wie eine Single-Page-App
  • Das Filtering erfolgt clientseitig über das gesamte domain-search-JSON
  • Getestet wurde, dass es auch mit Domains funktioniert, die mehr als 250.000 betroffene E-Mail-Adressen enthalten
  • Bei Daten in dieser Größenordnung ist es allerdings sinnvoller, sie über die API abzurufen, statt im Browser darin zu scrollen
• Auch die Verifizierung des Domain-Eigentums wurde komplett neu geschrieben
  • Sie wurde durch eine übersichtlichere und einfachere Oberfläche ersetzt
  • Bei Verifizierungsmethoden außerhalb von E-Mail bleibt noch Arbeit, um sie reibungsloser zu machen

API-Dokumentation und Merch-Store

• An der API selbst gibt es keine Änderungen
  • Dieses Update führt keine breaking changes ein
  • Für bestehende API-Nutzer geht nichts kaputt
• Die API-Dokumentation wurde nicht auf die neue Methode umgestellt und behält die bisherigen Dokumente bei
  • Im GitHub-Repo für den UX rebuild gab es Diskussionen über die Art der API-Dokumentation; der allgemeine Konsens war OpenAPI
  • Es wurde mit Scalar daran gearbeitet, sichtbar unter haveibeenpwned.com/scalar
  • Scalar bietet Beispiele in mehreren Sprachen und einen Test-Runner im Browser
  • Innerhalb des großen Launch-Zeitplans wurde das nicht fertig, daher wurden die bestehenden API-Dokumente im Stil der neuen Website weitergeführt
  • Sobald künftig mehr Zeit vorhanden ist, soll auf die Scalar-Implementierung gewechselt werden
• Der HIBP-Merch-Store ist unter merch.haveibeenpwned.com online
  • Er wird über Teespring betrieben
  • Alle Produkte werden zum Selbstkostenpreis verkauft, ohne Gewinn zu erzielen
  • Er ist als unterhaltsamer Versuch für die Community gedacht
• Für Sticker wird weiterhin der bestehende Sticker Mule store genutzt, weil die Teespring-Optionen nicht an die bisherige Qualität von Sticker Mule heranreichen
  • Zudem gibt es open source artwork, sodass man sie selbst dort drucken lassen kann, wo man möchte

Tech-Stack und Performance

• Der Ursprungsdienst läuft weiterhin auf Microsoft Azure
  • Die Website nutzt App Service
  • Die meisten APIs nutzen serverless Functions
  • Es werden storage-account-Funktionen wie SQL Azure Hyperscale, queues, blobs und tables verwendet
  • Der Code ist größtenteils C# und nutzt .NET 9.0 sowie ASP.NET MVC on .NET Core
• Auch Cloudflare spielt weiterhin eine große Rolle
  • In Workers steckt viel Code
  • Daten liegen in R2 storage
  • WAF- und Caching-Funktionen werden genutzt
  • Für anti-automation wird ausschließlich Cloudflare Turnstile genutzt; Google reCAPTCHA wurde vollständig entfernt
• Das Frontend nutzt eine aktuelle Bootstrap-Generation, SASS und TypeScript
  • CSS wird in SASS geschrieben
  • JavaScript wird in TypeScript geschrieben
• Auch bei der Website-Performance gibt es messbare Verbesserungen
  • Laut Pingdom-Tests wurde die Seitengröße um 28% reduziert
  • Die Zahl der Requests wurde um 31% reduziert
  • Bei der Ladezeit gibt es starke Schwankungen, daher wird kein großer Unterschied behauptet
  • Hervorgehoben wird, dass selbst nach 11 Jahren bei Webseitengröße und Request-Zahl zweistellige prozentuale Reduktionen erreicht wurden
• Elemente, die als Tracking- oder Werbelast gelten könnten, wurden nicht eingebaut
  • Die tatsächlichen Traffic-Statistiken basieren auf Traffic, der über Cloudflare edge node läuft
  • Das 1Password product placement besteht nur aus Text und Bild
  • Auch outbound clicks werden nicht verfolgt
  • Gespräche über product placement mit identity-theft-Unternehmen, die invasive Tracking-Zahlen erwarten, werden dadurch schwieriger

KI-Einsatz im Entwicklungsprozess

• ChatGPT wurde im Zuge des Neuaufbaus umfangreich eingesetzt, besonders in den letzten Tagen
  • Es wurde genutzt, um in Bootstrap icons ein passendes Icon für die Überschrift „Index“ zu finden
  • So wurde unter mehr als 2.000 Icons innerhalb von etwa 30 Sekunden ein passendes gefunden
• KI wurde auch zur Prüfung der Website-Migration eingesetzt
  • Sie sollte ein PowerShell script schreiben, das haveibeenpwned.com crawlt und eindeutige URLs ausgibt
  • Außerdem sollte sie ein script schreiben, das prüft, ob gefundene paths auf stage.haveibeenpwned.com existieren
  • Sie half dabei, die fehlende Datei security.txt zu finden
  • Sie fand auch Einträge, die nie existiert hatten, weshalb „trust, but verify“ nötig war
• Auch für kleinere Aufgaben wie CSS-Ratschläge, Cloudflare-rule-Konfiguration und Eigenheiten von .NET-Core-Webapps wurde sie genutzt
  • Der Anteil korrekter Antworten wird auf etwa 90% geschätzt
  • Die Einschätzung fällt stark positiv aus: Wer KI in der Softwareentwicklung nicht aktiv nutzt, mache es falsch

Launch und Turnstile-Probleme

• Die neue Website wurde nach Angaben des Autors früh am Sonntagmorgen ausgerollt
  • Fast alles lief gut, ein oder zwei kleine glitches wurden schnell behoben und deployed
  • Der Beitrag wurde zwei Tage nach dem Go-live veröffentlicht, um vorher möglichst viele Probleme zu bereinigen
  • In dieser Zeit wurden mehr als 12 neue Releases veröffentlicht und schnell iteriert
• Auch kleine Änderungen an Nutzungsbedingungen und Datenschutzerklärung kosteten viel Zeit
  • Kleine Updates der Datenverarbeitung und neue Services wie stealer logs mussten berücksichtigt werden
  • Die Arbeit mit Anwälten kostete mehrere Stunden und mehrere Tausend Dollar
• Cloudflare Turnstile ist eine anti-automation-Methode, die Traffic nicht wie Google reCAPTCHA an Google weitergibt
  • Sie kann vollständig unsichtbar implementiert werden
  • Im Browser erstellt ein Cloudflare script eine challenge, die zusammen mit dem HTTP-Request übermittelt und anschließend serverseitig verifiziert wird
  • In irgendeiner Form war sie bei HIBP bereits seit 2023 im Einsatz
• An Stellen, an denen Bot-Abwehr wichtig ist, etwa bei Formularen zum Versenden von E-Mails, wird Nutzern bei Turnstile-Fehlern ein Hinweis angezeigt, es erneut zu versuchen oder die Seite neu zu laden
  • Häufig ließ sich das durch einen zweiten Klick oder einen page reload lösen
  • Falls es nicht gelöst wird, muss eine auffälligere Turnstile-widget-Implementierung geprüft werden, bei der Nutzer interagieren müssen
• Auch auf der Hauptsuchseite wird Turnstile wichtig eingesetzt
  • Sie sendet asynchron Requests an einen API endpoint und übergibt dabei ein challenge token
  • Wenn eine fehlgeschlagene challenge dazu führt, dass der HIBP endpoint HTTP 401 und Invalid Turnstile token zurückgibt, musste ein Fallback auf einen full page post erfolgen
  • Beim ersten Launch der neuen Website funktionierte dieses Fallback nicht, wurde später aber korrigiert
  • Beim full page post wird eine Cloudflare managed challenge angezeigt; sie ist invasiver, aber zuverlässiger
• Laut Cloudflare-Statistiken wurden etwa 82% der ausgegebenen challenges erfolgreich gelöst
  • Ein großer Teil der nicht gelösten 18% könnten Bots sein, die Turnstile wie beabsichtigt blockiert hat
  • Der Anteil echter Menschen, deren Requests blockiert wurden, liegt wahrscheinlich im einstelligen Prozentbereich; es muss weiter geprüft werden, wie diese Zahl gesenkt werden kann