¿Me han superado? permite a cualquiera descargar la base de datos completa para realizar las comprobaciones localmente.

Si esa no es una opción, usar la API es seguro, ya que usa k-anonimity que le permite realizar la verificación sin transmitir la contraseña completa / hash.

Si el operador de la API de Pwned Passwords es malicioso (o el servicio es pirateado por una persona malintencionada o alguien intercepta su comunicación) puede mentir sobre ciertas contraseñas (solo devolver un subconjunto de contraseñas que sepa para ese hash), registre de dónde provino la solicitud, identifique el sitio web que pertenece a esa ID, identifique la cuenta (según el tiempo de creación, por ejemplo) y pruébela con las contraseñas sobre las que mintió, para obtener una buena oportunidad de compromiso con la cuenta.

Este es un escenario bastante improbable (el propietario de la API es un profesional de seguridad respetable, la lista de hashes conocidos es pública, y hacer este tipo de ataque sin ser detectado sería difícil), por lo que depende de cómo de riesgo averso eres Si ejecuta un panel de discusión, usar la API es definitivamente una buena idea. Si ejecuta un banco electrónico, tal vez no tanto.

Por supuesto, descargar la base de datos y realizar las comprobaciones localmente es más seguro, pero no es una tarea trivial, dado el tamaño.

Según lo solicitado, No.

A partir de la publicación de esta respuesta, la pregunta se pregunta si es seguro enviar una contraseña "antes de agregarla y picarla", lo que significa en texto simple. Usted debe nunca enviar una contraseña en texto simple a un tercero (la segunda parte puede estar bien si actualmente está iniciando sesión). Incluso el hashing de la contraseña no es suficiente, ya que se puede utilizar una Rainbow Table para buscar la contraseña. Esta es la razón por la que cuando vi a alguien (hashing y) enviando cada contraseña en una base de datos KeePass a HIBP , Los llamé inmediatamente.

Como han señalado otras respuestas, hay una nueva versión de HIBP que incluye k- anonimato (vea ese enlace y las otras respuestas para obtener más información). Sin embargo, esto todavía es divulgar alguna información sobre las contraseñas (a HIBP y cualquier posible MITM atacante. Divulgar algo de información no es tan malo como filtrar la contraseña completa, pero es algo que debería preocuparle. Lo que realmente desea es que sus contraseñas sean seguro, no anónimo .

En última instancia, si desea asegurarse de que no se filtre información sobre sus contraseñas en el proceso de verificación, debe descargar la Base de datos completa de contraseñas pwned y hash y verifique su contraseña localmente (en este caso, en el servidor porque nadie quiere descargar la base de datos completa solo para crear una cuenta). Simplemente no almacene la contraseña o el hash que está comparando con la base de datos en cualquier lugar, solo almacene el hash salado en su base de datos de contraseñas real.

Solo para agregar algo a las respuestas anteriores, no puedo pensar en ningún otro problema serio de seguridad al comparar contraseñas con el sitio, pero desde la perspectiva de la experiencia del usuario, sería mejor revisar el correo electrónico y la contraseña juntos y luego notificar al usuario si ambos devuelven true. Tampoco les impediría que lo usaran si vuelve a ser verdadero. Acabo de probar 30 contraseñas aleatorias recién generadas y 4 de ellas se volvieron verdaderas en el sitio. No estoy 100% seguro de cómo lo implementaría utilizando la API, pero probablemente sería lo que buscaría hacer.