Have I Been Pwned 2.0

• El servicio de verificación de filtraciones de datos Have I Been Pwned fue renovado por completo
• Junto con el nuevo diseño, las principales funciones de las páginas web cambiaron y mejoraron de forma importante
• La función de búsqueda ahora es más intuitiva, y se reforzó la orientación sobre cómo verificar cuentas y sobre distintos casos de brechas de datos
• Se añadieron varias funciones nuevas y mejoradas, como panel de usuario, búsqueda de dominios y documentación de la API
• El rendimiento web y la seguridad se implementaron sobre una infraestructura moderna en la nube, ofreciendo una experiencia rápida y segura para el usuario

---

Introducción y contexto

• Have I Been Pwned (en adelante, HIBP) 2.0 se presentó completamente renovado tras un largo período de desarrollo
• El primer commit fue en febrero de 2023, y tras un soft launch en marzo de 2024 y el proceso de open source, el sitio abrió con una reconstrucción total y una nueva identidad de marca
• Se rediseñaron por completo la estructura y las funciones del sitio, y junto con nuevas características también se abrió una tienda de merchandising

Función de búsqueda

• El buscador principal, la función más representativa de HIBP, se mejoró para ser más intuitivo y con una presentación más fresca (animación de confeti)
• Para que la experiencia de usuario no se sintiera pesada, se evitó una atmósfera demasiado negativa y se puso el foco en ofrecer al usuario información práctica basada en hechos
• La búsqueda por nombre de usuario y número telefónico fue eliminada del sitio web (aunque en la API se mantiene como antes)
  • La búsqueda basada en direcciones de correo electrónico es más adecuada en términos de parsing, alertas y consistencia del servicio
  • Se decidió excluir números telefónicos y nombres de usuario para reducir confusión, ya que implican una alta carga de procesamiento de datos y casi no se usan en la práctica

Página de casos de brechas de datos

• Ahora cada incidente de brecha o filtración cuenta con una página dedicada de detalle
• Con un diseño más intuitivo y agradable que antes, se ofrece orientación concreta y accionable sobre el impacto y cómo responder
• Se planea añadir más información, como datos adaptados por región, en colaboración con otras instituciones (por ejemplo, NCSC)
• Más adelante se incorporarán detalles como soporte para 2FA, passkeys y guías personalizadas para usuarios

Panel

• Varias funciones existentes (verificación de brechas sensibles, gestión de dominios, gestión de suscripciones, etc.) se unificaron en un panel integrado
• El panel se accede mediante verificación por correo electrónico, y más adelante también se agregarán nuevos métodos de autenticación como passkeys
• También abre la posibilidad de evolucionar hacia una plataforma ampliable con funciones futuras como alertas para cuentas familiares

Función de búsqueda de dominios

• La función de verificación y búsqueda de dominios fue rediseñada por completo, con una UI más limpia y soporte para varios filtros (por ejemplo, ver solo filtraciones recientes)
• Con una estructura completamente de aplicación de página única (SPA), los resultados de búsqueda se entregan rápidamente en JSON a través de la API
• El proceso de verificación de propiedad del dominio también se simplificó desde cero
• Se prevén mejoras aparte para métodos de autenticación distintos del correo electrónico

API

• En esta actualización no hubo absolutamente ningún cambio ni interrupción en la API en sí
• Para la documentación de la API se prepara la adopción de la herramienta Scalar basada en OpenAPI, pero por ahora se mantiene la documentación existente con un nuevo estilo unificado
• Más adelante se migrará a documentación moderna basada en Scalar

Merchandising y stickers

• Se abrió oficialmente la tienda de productos de marca de HIBP, comenzando con la venta de camisetas y otros artículos (basada en Teespring, sin margen de ganancia)
• Los stickers siguen disponibles en la tienda de Sticker Mule, y el arte se puede usar libremente porque es open source

Tecnología e infraestructura

• El backend del sitio está basado en Microsoft Azure, usando App Service, Functions, Hyperscale SQL, Storage y más
• La aplicación web principal está escrita con C# y .NET 9.0, usando ASP.NET MVC (.NET Core)
• Cloudflare se aprovecha ampliamente para WAF, caché, Turnstile (anti-bot), almacenamiento R2 y más
• En el frontend se implementó una interfaz moderna sobre Bootstrap reciente, SASS y TypeScript
• Gracias a las contribuciones de miembros clave como el desarrollador islandés Ingiber, se logró un alto nivel de acabado y una UI atractiva
• Se redujo aproximadamente en 28% el peso de las páginas web y en 31% la cantidad de solicitudes, logrando una optimización más efectiva que hace 11 años
• Se eliminaron por completo elementos innecesarios como tracking y datos publicitarios, priorizando la privacidad del usuario

Uso de IA

• Durante la reconstrucción del sitio se utilizó activamente Chat GPT para resolver diversos problemas de desarrollo, como CSS, recomendaciones de íconos, configuración de Cloudflare y particularidades de .NET Core
• Con las sugerencias rápidas de la IA y la automatización de código, se experimentó una gran mejora en productividad
• También se comprobó una alta precisión y utilidad en migraciones rápidas y automatización de tareas

Recorrido de desarrollo y conclusión

• Diversas tareas poco visibles, como la actualización de documentos legales, requirieron mucho tiempo y costo
• Antes y después del lanzamiento se realizaron varias correcciones urgentes y lanzamientos iterativos para resolver problemas con rapidez
• Sin perder la esencia original, se completó este relanzamiento manteniendo la especialización, escalabilidad y comodidad del servicio
• HIBP es el resultado de una pasión a la que se ha dedicado una cuarta parte de la vida desde 2013, y con esta versión 2.0 se espera un nuevo impulso como servicio para la comunidad

[GN⁺]

Opiniones de Hacker News

• Imaginan que podría asociarse con un bufete de abogados, compartir un llamado a impulsar demandas colectivas por todas las filtraciones de datos causadas por negligencia —o sea, prácticamente todas— y, conectado con un servicio bancario de pagos, enviar directamente las indemnizaciones a millones de personas; así se convertiría en un héroe moderno. También enfatizan la importancia de colaborar con abogados capaces de lograr fallos realmente dolorosos para las empresas negligentes, y advierten que los acuerdos pequeños solo corren el riesgo de permitir que continúe una gestión irresponsable. Como opción adicional, mencionan la posibilidad de vender a firmas de inversión datos sobre demandas inminentes. En última instancia, desean que se forme un clima social donde tan solo la noticia de una filtración de datos golpee naturalmente la cotización de esa empresa.
  • Comentan que si cada vez que hubiera una indemnización se pudiera donar de inmediato una pequeña parte a una buena causa, habría más motivación para unirse a una demanda colectiva.
  • Bromean con la ansiedad de cuánto tardaría en filtrarse también la información almacenada en ese propio servicio bancario.
  • Les preocupa que un sistema así pueda ser contraproducente. Si ya de por sí es difícil que las empresas revelen una filtración, una estructura como esa solo aumentaría el riesgo y haría que intentaran ocultarlo aún más. Opinan que es mejor saber si su información fue filtrada para poder cambiar la contraseña.
  • Expresan que todavía siguen esperando el día en que Blue Shield los compense por haber vendido su información personal a Google, y dicen que usarían el servicio.
• Les sorprende que, hace apenas unos 10 años, un sitio gigantesco como LinkedIn almacenara contraseñas sin sal. Se preguntan cómo era posible cometer ese error en tiempos modernos.
  • Explican que este tipo de cosas puede pasar con más facilidad de lo que parece. Desde la perspectiva del middleware, el campo password dentro de un JSON puede verse simplemente como otro campo más, y si una API o un sistema de logging guarda el cuerpo completo de la solicitud, el problema puede ocurrir de verdad. Guardar contraseñas sin sal directamente en un almacén de contraseñas sería raro, pero comparten la experiencia de que algo parecido puede suceder si, por ejemplo, en el gateway de API de una app Android se omite que un flujo como “recuperar contraseña” contiene información sensible.
  • Opinan en tono de broma que estos errores ocurren porque en las entrevistas de ingeniería no ponen suficientes problemas Leetcode Hard.
  • Señalan que se habla mucho de AI Slop, pero que desde hace tiempo también existe un grave problema de Outsourced Slop. Según su experiencia, es muy probable que en LinkedIn la causa principal también hayan sido entregables de programadores tercerizados. Sostienen que solo un gerente fuerte y competente, que fije estándares de calidad y los verifique, puede evitar productos que por fuera se ven bien pero por dentro son endebles.
  • Indican que estos errores también pueden deberse a sistemas viejos y abandonados, como mainframes legados construidos hace mucho tiempo, a los que nadie puede dedicar tiempo ni presupuesto para mantener o migrar. Cuanto más grande es la empresa, más fuerte se vuelve la fosilización de los sistemas críticos, hasta el punto de que incluso una interrupción de una hora ya se considera una “pérdida” de millones, lo que hace aún más imposible darles mantenimiento.
• Creen que mucha gente común usa Have I Been Pwned con frecuencia y que derivar tráfico a 1Password es una de las mejores opciones. Mencionan que la promoción con 1Password encaja de maravilla. Sugieren que el texto del banner debería destacar más, algo como “muy recomendado”. Enfatizan que gran parte de los hackeos a cuentas sociales se debe a la reutilización de contraseñas y que, por esa experiencia, educar sobre contraseñas seguras y llevar a la gente a un gestor de contraseñas es algo muy positivo. Comparten que en el último año ayudaron realmente a resolver más de 20 casos y felicitan por la renovación.
• Les impresiona esa función aterradora pero increíble que muestra todas las filtraciones de datos en un desplazamiento vertical, con logos y textos de presentación.
  • Dicen que al ver las filtraciones sienten impotencia y que, aparte de congelar el crédito, casi no hay medidas que puedan tomar.
• Se preguntan quién tendrá el récord de más filtraciones de datos. Comparten que su correo principal ha aparecido en 40 filtraciones hasta ahora; la más antigua es de junio de 2011 (HackForums, que ni recuerdan) y la más reciente de septiembre de 2024 (FrenchCitizens, sin tener ninguna relación con Francia).
  • Otra persona responde que superó ese récord por una sola filtración.
  • Comparten el sorprendente dato de que el correo [e-mail] apareció en nada menos que 322 filtraciones.
• Como consejo para quien quiera más privacidad, comentan que el servicio tiene una función de opt-out para ocultar los resultados de búsqueda de su correo.
• Como usan varios alias de correo, dicen que no pueden buscarlos uno por uno y que les gustaría una función para buscar todo de una vez por dominio.
  • Les responden que en "The Domain Search Feature", tras verificar la propiedad del dominio, se pueden ver todos los resultados de una sola vez.
• Dicen que es un sitio realmente genial y esperan que el gobierno tome este problema más en serio. Subrayan que el robo de identidad, el secuestro de cuentas y problemas similares al final empiezan con filtraciones de datos, y que hoy en día sufrir el saqueo de cuentas digitales es un desastre aún más grave que un robo en casa. En el caso de una intrusión física existen claramente llamadas al 911, denuncias y seguimiento, pero ante una intrusión digital no hay a quién contactar ni existe mucho proceso de resolución, así que piden un cambio en la respuesta social.
• Evalúan muy positivamente el rediseño y comentan que seguir las actualizaciones de Troy también es entretenido, aunque a veces se siente como un humor negro interesante. Les pareció que la cronología estaba ordenada desde la filtración más antigua hasta la más reciente, pero se confundieron porque la fecha mostrada no es la del momento en que ocurrió la filtración, sino la de cuando se hizo pública. Como solución, sugieren que tanto el orden como la etiqueta se basen en la “fecha de divulgación”, y que dentro de cada tarjeta se indique aparte la fecha real de la filtración en un formato estándar.