Have I Been Pwned 2.0 ya está disponible

• El esperado rebranding de HIBP pasó al servicio real, con una reconstrucción completa del sitio web y una renovación funcional de casi todas las páginas
• La búsqueda principal mejoró la experiencia de resultados, pero en el sitio web se eliminaron las búsquedas por username y phone number, mientras se mantiene la compatibilidad con la API existente
• Las nuevas páginas por filtración hacen que los resultados de búsqueda sean menos complejos y separan en una pantalla aparte las acciones concretas que el usuario puede tomar después de un incidente
• Las funciones que requieren verificar acceso al correo electrónico se agruparon en un dashboard basado en Sign In, y domain search funciona más rápido con una API JSON y filtrado del lado del cliente
• El stack técnico quedó centrado en Azure, Cloudflare, .NET 9.0, Bootstrap y TypeScript; se eliminó Google reCAPTCHA y solo se usa Cloudflare Turnstile

---

Nuevo sitio web y experiencia de búsqueda

• Se lanzó el nuevo sitio web de Have I Been Pwned
  • El primer commit del trabajo de rebranding en el repositorio público se hizo en febrero de 2024
  • La nueva marca tuvo un lanzamiento suave en marzo de 2025
  • Esta versión incluye una reconstrucción completa del sitio web, cambios funcionales en casi todas las páginas, nuevas funciones y el lanzamiento de una tienda de merchandising
• El cuadro de búsqueda principal mantiene la función emblemática de HIBP, pero cambia la forma de mostrar los resultados
  • Algunos usuarios verán una reacción de felicitación y una animación de confetti
  • Cuando se confirma una filtración, muestra una respuesta roja más sobria
  • Los resultados se presentan como una timeline desplazable en orden cronológico inverso, junto con un resumen de cada filtración
• En la búsqueda del sitio web se eliminó el soporte para username y phone number
  • La búsqueda por username se introdujo en 2014 para el incidente de Snapchat
  • La búsqueda por phone number se introdujo en 2021 para el incidente de Facebook
  • Esos dos tipos de datos nunca se cargaron fuera de esos dos casos
  • Con username es difícil identificar al propietario, y phone number es complicado de parsear por los formatos internacionales y las diferencias de escritura
  • Las notificaciones por SMS tienen un costo mucho más alto que las de correo electrónico
  • Al permitir esa entrada en el sitio anterior, surgían confusiones y carga de soporte por preguntas como “por qué mi número no aparece en una filtración específica”
  • En la API seguirá soportándose para mantener la compatibilidad, pero se aclaró que no se debe esperar que se agreguen más datos

Páginas dedicadas por filtración

• La nueva breach page separa la información detallada de cada filtración en una pantalla aparte para reducir la complejidad de los resultados principales
  • Un ejemplo es la breach page de Ashley Madison
  • Muestra la información existente de una forma más amigable para el usuario
• El cambio central de la página está en ofrecer una guía más concreta sobre las acciones que puede tomar el usuario después de una filtración
  • Se enfoca en qué debe hacer un usuario afectado por una filtración
  • También incluye la posibilidad de conectarlo con servicios de socios, como proveedores de protección de identidad
• A futuro se planea reforzar más los datos por filtración y por usuario
  • Si el servicio en cuestión soporta 2FA, se mostrará eso de forma específica en vez de una guía genérica
  • También se planea agregar una sección separada para passkey
  • En conversaciones con el NCSC del Reino Unido, se trató una guía localizada sobre filtraciones de datos que muestre a usuarios del Reino Unido el logo del NCSC y recursos de orientación relacionados

Dashboard integrado y búsqueda de dominios

• A medida que durante varios años fueron aumentando las funciones que requieren confirmar acceso a una dirección de correo electrónico, se integraron en un único central dashboard
  • En el caso Ashley Madison de 2015 se introdujo el concepto de sensitive breach, lo que hizo necesario verificar mediante recepción de correo
  • En 2019, para reducir el abuso de la API, se agregó una capa de autenticación a la API y se exigió verificar el correo antes de comprar una API key
  • Luego se agregaron el domain search dashboard, la gestión de suscripciones pagas y la consulta de stealer logs
• El nuevo dashboard verifica el acceso a la dirección de correo electrónico detrás de un único Sign In y luego muestra las funciones relacionadas
  • Incluye funciones para el público general y funciones orientadas a negocios
  • A futuro se planea agregar soporte para passkey para iniciar sesión sin enviar correos
  • También se menciona como ejemplo adecuado para el dashboard la función de registrar direcciones de correo de familiares para suscribirse a alertas, pero recibir las notificaciones en otra dirección
• domain search recibió muchas mejoras de organización visual y filtrado
  • La lista de dominios verificados quedó más limpia
  • Los resultados de búsqueda ofrecen un resumen más claro
  • Se agregaron filtros por dirección de correo electrónico y un filtro para ver solo la “latest breach”
• El dashboard de búsqueda de dominios recibe JSON desde la API y todo el dashboard funciona como una aplicación de una sola página
  • El filtrado se realiza del lado del cliente sobre todo el JSON de domain search
  • Se probó que puede funcionar incluso con dominios que tienen más de 250.000 direcciones de correo filtradas
  • Sin embargo, para datos de ese tamaño es más apropiado recibirlos por API que desplazarse por ellos en el navegador
• La verificación de propiedad de dominios también se reescribió por completo
  • Cambió a una interfaz más limpia y simple
  • Los métodos de verificación distintos al correo electrónico aún requieren trabajo para hacerlos más fluidos

Documentación de la API y tienda de merchandising

• La API en sí no cambió
  • Esta actualización no introduce cambios incompatibles
  • Nada se rompe para los usuarios existentes de la API
• La documentación de la API no pudo migrarse al nuevo enfoque y mantiene la documentación anterior
  • En el repositorio de GitHub del UX rebuild hubo discusiones sobre la forma de documentar la API, y el consenso general fue OpenAPI
  • Se avanzó con trabajo usando Scalar, que puede verse en haveibeenpwned.com/scalar
  • Scalar ofrece ejemplos en varios lenguajes y un runner de pruebas dentro del navegador
  • Como no se logró completarlo dentro del gran calendario de lanzamiento, se mantuvo la documentación existente de la API adaptada al estilo del nuevo sitio
  • Cuando haya más margen en el futuro, se planea pasar a la implementación con Scalar
• La tienda de merchandising de HIBP se lanzó en merch.haveibeenpwned.com
  • Opera mediante Teespring
  • Todos los productos se venden al costo y no generan ganancias
  • Se preparó como una iniciativa divertida para la comunidad
• Para los stickers se seguirá usando la tienda de Sticker Mule, porque las opciones de Teespring no alcanzaban la calidad anterior de Sticker Mule
  • También está disponible el arte open source, para poder imprimirlo por cuenta propia donde se quiera

Stack técnico y rendimiento

• El servicio original sigue operando en Microsoft Azure
  • El sitio web usa App Service
  • La mayoría de la API usa Functions serverless
  • Usa funciones de storage account como SQL Azure Hyperscale, queues, blobs y tables
  • El código es mayormente C#, y usa .NET 9.0 y ASP.NET MVC on .NET Core
• Cloudflare también sigue teniendo un papel importante
  • Hay mucho código en Workers
  • Hay datos en R2 storage
  • Usa funciones de WAF y caching
  • Para anti-automation solo usa Cloudflare Turnstile y eliminó por completo Google reCAPTCHA
• El frontend usa generaciones modernas de Bootstrap, SASS y TypeScript
  • El CSS está escrito en SASS
  • El JavaScript está escrito en TypeScript
• El rendimiento del sitio web también tiene mejoras medibles
  • Según pruebas de Pingdom, el tamaño de página se redujo en 28%
  • La cantidad de requests se redujo en 31%
  • Como el tiempo de carga es muy variable, no se afirma una gran diferencia
  • Se destaca que, incluso 11 años después, se redujeron en porcentajes de dos dígitos el tamaño de página y la cantidad de requests
• No se agregaron elementos que puedan verse como carga de tracking o publicidad
  • Las estadísticas reales de tráfico se basan en el tráfico que pasa por el edge node de Cloudflare
  • El product placement de 1Password solo consiste en texto e imagen
  • Tampoco se rastrean los outbound clicks
  • Esto dificulta más las conversaciones de product placement con empresas de identity theft que esperan métricas de tracking invasivo

Uso de AI durante el desarrollo

• ChatGPT se usó ampliamente durante la reconstrucción, especialmente en los últimos días
  • Se usó para encontrar un ícono adecuado para el heading “Index” dentro de Bootstrap icons
  • Se usó para encontrar en unos 30 segundos un ícono apropiado entre más de 2.000
• También se usó AI para verificar la migración del sitio
  • Se le pidió escribir un script de PowerShell que rastreara haveibeenpwned.com e imprimiera URLs únicas
  • También se le pidió escribir un script que verificara si los paths encontrados existían en stage.haveibeenpwned.com
  • Ayudó a encontrar un archivo security.txt faltante
  • También detectó elementos que nunca habían existido, por lo que fue necesario aplicar “confía, pero verifica”
• Se utilizó también para tareas pequeñas como consejos de CSS, configuración de reglas de Cloudflare y particularidades de una app web en .NET Core
  • Se estimó que las respuestas fueron correctas aproximadamente el 90% de las veces
  • La valoración fue tan positiva que afirmó que, si no se usa AI activamente en desarrollo de software, se está haciendo mal

Lanzamiento y problemas con Turnstile

• El nuevo sitio se desplegó un domingo temprano por la mañana, según el autor
  • Casi todo salió bien, y uno o dos pequeños glitches se corrigieron y desplegaron rápidamente
  • El artículo se publicó 2 días después de estar en vivo para primero ordenar la mayor cantidad posible de problemas
  • En ese intervalo se desplegaron más de 12 nuevos releases con mejoras iterativas rápidas
• Incluso cambios pequeños en los términos y la política de privacidad llevaron mucho tiempo
  • Fue necesario reflejar pequeñas actualizaciones en la forma de procesar datos y nuevos servicios como stealer logs
  • El trabajo con abogados tomó varias horas y miles de dólares
• Cloudflare Turnstile es un método anti-automation que no envía el tráfico a Google como Google reCAPTCHA
  • Puede implementarse de forma completamente invisible
  • En el navegador, el script de Cloudflare crea un challenge que luego se envía junto con la solicitud HTTP y se valida del lado del servidor
  • En HIBP estaba aplicado de alguna forma desde 2023
• En lugares donde bloquear bots es importante, como formularios que envían correos, si Turnstile falla se muestra al usuario una indicación para intentar de nuevo o recargar la página
  • En muchos casos, un segundo clic o recargar la página lo resolvía
  • Si no se resuelve, habrá que evaluar una implementación más visible del widget de Turnstile, que requiera interacción del usuario
• Turnstile también se usa de forma importante en la página principal de búsqueda
  • Hace una solicitud asíncrona al endpoint de la API y envía junto con ella el challenge token
  • Si el challenge fallaba y el endpoint de HIBP devolvía HTTP 401 con Invalid Turnstile token, debía hacer fallback a un full page post
  • En el lanzamiento inicial del nuevo sitio, ese fallback no funcionaba, pero luego fue corregido
  • En el full page post se muestra un Cloudflare managed challenge, más invasivo pero más confiable
• Según las estadísticas de Cloudflare, alrededor del 82% de los challenges emitidos se resolvieron correctamente
  • Una parte importante del 18% no resuelto podría corresponder a bots bloqueados por Turnstile tal como se esperaba
  • Es posible que las solicitudes de personas reales bloqueadas estén en un porcentaje de un solo dígito, y habrá que seguir viendo cómo reducir esa cifra