Te haría bien leer sobre por qué Troy creó la lista de contraseñas pwned en primer lugar .

Las pautas de NIST son bastante explícitas sobre qué hacer: "Si el secreto elegido se encuentra en la lista, el CSP o el verificador DEBERÁN informar al suscriptor que deben seleccionar un secreto diferente, DEBEN proporcionar el motivo del rechazo, y DEBERÁ exigir al suscriptor que elija un valor diferente ". (énfasis mío)

Bloquea la contraseña incorrecta. Dígales por qué lo está bloqueando. Para obtener puntos de bonificación, sugiera una contraseña generada al azar que puedan usar en su lugar, o haga un enlace a un sitio que describa cómo generar una (o proporcione una lista de administradores de contraseñas).

O, como han dicho otros, use algún tipo de autenticación de terceros, por ejemplo, "iniciar sesión con Google" o "iniciar sesión con Facebook".

Si se le puede responsabilizar de cualquier forma por los daños causados por los datos filtrados de su sitio web, aunque podría rastrearse hasta la reutilización de contraseñas conocidas, siempre me atrevería a obligar a las personas a elegir. otra contraseña.

La mayoría de la gente siempre va por la salida fácil, por lo que la opción 1 resultará en que sigan usando la contraseña incorrecta, al igual que la opción 3. La única forma de asegurarse de que usted no sufrirá la Los resultados de su mal manejo de las contraseñas, es forzándolas.

Actualmente, haveIbeenpwned tiene 517,238,891 contraseñas. Para evitar complicar demasiado las cosas, supongamos que tienen 10 caracteres de un conjunto de 86 caracteres. Eso es 1.37e19 contraseñas posibles si fueran aleatorias, pero la estimación de Nist sugiere que la cantidad de contraseñas que los usuarios realmente elegirán (4 bits para el primer carácter, 2 bits para los caracteres 2-8, 1.5 bits para los caracteres 9 en) es inferior a 2,100,000. Aunque espero que la cantidad de contraseñas citadas por haveIbeenpwned sea la cantidad de instancias en lugar de valores únicos, todavía sugiere que una gran proporción de propuestas de contraseña encontrarán una coincidencia en la base de datos.

El riesgo proviene de que un atacante conozca una combinación de una contraseña y una identificación de usuario.

En base a lo anterior, el motivo de los intentos de autenticación de limitación de velocidad debe ser obvio.

Las contraseñas apestan.

No dijiste si tu objetivo es proteger a tus usuarios o protegerte a ti mismo. Hay formas de transferir la responsabilidad por:

• recordando a los usuarios la buena práctica de contraseñas (no reutilice las contraseñas) y exija que reconozcan el mensaje. Siempre puede verificar más tarde, o incluso verificar en el momento si la contraseña está en el conjunto de haveIbennpwned sin usarla para dirigir el flujo de interacción
• confíe en otra persona para que administre la autenticación, generalmente mediante openID

Tampoco mencionó cuál es la naturaleza de su relación con sus clientes. Usted puede perder el negocio haciendo el registro demasiado oneroso.

Si bien nadie puede darle una respuesta definitiva como la solución "correcta", si tuviera que realizar pruebas AB de los diferentes enfoques, entonces podría al menos medir el efecto en la percepción que el cliente tiene de su sitio.

Creo que solo tienes dos opciones que tienen sentido:

1. Bloquee la contraseña y comunique al usuario la razón de manera muy detallada y comprensible. Es decir, dígales que su contraseña se considera insegura porque se incluye en una base de datos de contraseñas que ahora se consideran inseguras. Necesitan usar otro. Probablemente lo entenderán y hasta podrían alegrarse de haber aprendido algo nuevo.
2. Permita que el usuario elija la contraseña que desee, siempre que tenga suficiente entropía (verifique su longitud, etc.) y tiene un sistema de prevención de fuerza bruta (mucho tiempo entre inicios de sesión fallidos, CAPTCHAs, prohibiendo IPs después de demasiados intentos, etc.).

¿Por qué creo que la opción # 2 no es insegura?

1. A menos que mi impresión y mis cálculos sean incorrectos, no creo que los ataques de fuerza bruta en línea vayan a probar demasiadas contraseñas. Solo intentarán algunas contraseñas (las más comunes) y luego pasarán a otra cuenta para hacer lo mismo. En este momento, parece haber tenido más de mil millones de contraseñas "inseguras". Así, por ejemplo, a una velocidad de 1 contraseña por segundo (considerando retrasos, captchas, bloqueos, prohibiciones, etc.) llevaría alrededor de 15 años probarlos todos. Es posible que pueda acelerarlo utilizando varias direcciones IP, etc., pero aún así tomaría demasiado tiempo. Nadie haría eso, tal vez ni siquiera si fue un ataque dirigido (probablemente considerarán otras opciones).
2. Para los ataques fuera de línea, que pueden ser muy rápidos, el atacante probablemente intentará todas las contraseñas en la lista de privilegios, pero probablemente no se detendrán allí: intentarán más, quizás algunas variaciones basadas en esa lista, ¿y adivina qué? Cuando a un usuario le gusta una determinada contraseña y se le obliga a cambiarla, es posible que solo use una pequeña variación de la misma. Además, si el atacante puede restringir las contraseñas fuera de línea, es posible que tenga problemas peores: su software probablemente tenga algunas vulnerabilidades graves que lo permitieron, otros datos podrían haber sido robados o comprometidos (incluido el propio software, por lo que las contraseñas podrían leído en texto sin formato en cada inicio de sesión), etc.

Para decirle la verdad, generalmente me preocupa más el hecho de que los usuarios a menudo usan la misma contraseña en todas partes, o pequeñas variaciones en casi todas partes. Y, lamentablemente, no hay manera de obligar a esos usuarios a dejar de hacer eso.