Descargo de responsabilidad: soy el autor, creador, propietario y mantenedor de Have I Been Pwned y el servicio de contraseñas Pwned vinculado.
Permítame aclarar todos los puntos planteados aquí:
El propósito original de HIBP era permitir a las personas descubrir dónde se había expuesto su dirección de correo electrónico en las violaciones de datos. Ese sigue siendo el caso de uso principal del servicio hoy en día y hay casi 5 millones de registros allí para ayudar a las personas a hacer eso.
Agregué Pwned Passwords en agosto del año pasado después de que NIST publicara un montón de consejos sobre cómo fortalecer los modelos de autenticación. Parte de ese consejo incluía lo siguiente :
Al procesar solicitudes para establecer y cambiar secretos memorizados, los verificadores DEBEN comparar los posibles secretos con una lista que contenga valores que se sabe que son utilizados, esperados o comprometidos. Por ejemplo, la lista PUEDE incluir, pero no se limita a: Contraseñas obtenidas de corpuses de infracciones anteriores.
Eso es a lo que se refieren las contraseñas de Pwned: NIST aconsejó "qué" debes hacer pero no proporcionó las contraseñas por sí mismas. Mi servicio aborda la parte de "cómo".
Ahora, en la práctica, ¿cuánta diferencia hace? ¿Es realmente como usted dice que es como una situación de un millón en la puerta principal? Bueno, en primer lugar, incluso si era , el ejemplo de IRL se rompe porque no hay forma de que una persona anónima en el otro lado del mundo pueda probar su llave de la puerta de entrada en millones de Puerta de forma rápida, anónima. En segundo lugar, la distribución de contraseñas no es de ninguna manera lineal; las personas eligen las mismas cagadas una y otra vez y eso pone a esas contraseñas en un riesgo mucho mayor que las que raramente vemos. Y, finalmente, el relleno de credenciales es rampante y es un problema muy serio para las organizaciones con servicios en línea. Continuamente escucho de las compañías los desafíos que tienen con los atacantes que intentan iniciar sesión en las cuentas de las personas con credenciales legítimas . No solo es difícil de detener, sino que también puede hacer responsable a la empresa, esto apareció la semana pasada: "El mensaje de la FTC es alto y claro: si los datos del cliente se pusieron en riesgo por relleno de credenciales , luego ser la víctima corporativa inocente no es una defensa para un caso de aplicación" enlace
Haber visto una contraseña en una violación de datos antes es solo un indicador de riesgo y es uno en el que cada organización que usa los datos puede decidir cómo manejarlos. Pueden pedir a los usuarios que elijan otro si lo han visto muchas veces antes (hay un recuento al lado de cada uno), marcar el riesgo para ellos o simplemente marcar la cuenta en silencio. Esa es una defensa junto con MFA, anti-automatización y otras heurísticas basadas en el comportamiento. Es simplemente una parte de la solución.
Y de forma incidental, las personas pueden usar el modelo de anonimato k (disponible gratuitamente) a través de API, que permite proteger la identidad de la contraseña de origen o simplemente descargar el conjunto completo de hashes (también disponible gratuitamente) y procesarlos en la zona. Sin términos de licencia, sin requisitos de atribución, solo ve y haz cosas buenas con él :)