¿Debo implementar un retraso de contraseña incorrecto en un sitio web o un servicio web?

Supongo que su intención con el retraso de falla es evitar los ataques de fuerza bruta: si un atacante intenta adivinar la contraseña de un usuario, primero fallará muchas veces; Si podemos hacer que esas fallas tomen una cantidad de tiempo substancial, entonces hará que el ataque sea un orden de magnitud más difícil, y por lo tanto, es poco probable que tenga éxito (en un marco de tiempo razonable).

Sin embargo.

Esto supone que el atacante espera pacientemente entre los intentos de inicio de sesión. Y, como todos sabemos, los hackers cibernéticos son una gente muy educada y paciente.
Dicho esto, algunos atacantes pueden elegir NO esperar y simplemente enviar muchas solicitudes en paralelo. Si un intento de inicio de sesión no recibe una respuesta de inmediato, el atacante puede interpretarlo como un intento fallido, cancelar esa solicitud y pasar a la siguiente.

Un beneficio adicional de este esquema es que sería mucho más fácil para un atacante crear una carga irrazonable en el servidor (solo envíe muchas solicitudes de inicio de sesión fallidas, cada una ocupará un hilo durante varios segundos ...) , y posiblemente incluso tener éxito en DoSing el servidor.

De hecho, el principal problema con esta solución es que precisamente NO evita muchas solicitudes paralelas. Si un atacante intenta un ataque de fuerza bruta en línea, no se sentará frente al teclado escribiendo muchas contraseñas, una después de la otra, tan rápido como Hugh Jackman pueda. Si ese fuera el caso, solo estaría en riesgo si el usuario tiene una contraseña simple muerta.
En realidad, tendrá un script o una herramienta automatizada que enviará (casi) tantas solicitudes como pueda manejar el servidor, y luego continuará. El riesgo no es que alguien intente 30 contraseñas diferentes por minuto, es 1000 contraseñas por minuto, o 10,000.

La forma única de evitar esto es la limitación del usuario / bloqueo de la cuenta / suspensión incremental: llámelo como quiera, esta es básicamente la misma idea de permitir el número X de intentos de inicio de sesión por cuenta dentro de un período de tiempo determinado.
Entonces, aunque esto no se reduce a "un solo intento de inicio de sesión a la vez", se acerca lo suficiente.

Parte del problema es que mantener la conexión abierta mientras espera a que caduque la demora usa recursos valiosos, particularmente en ciertas configuraciones populares donde el número de conexiones simultáneas permitidas es bastante mínimo.

Una solución ideal es diseñar su sistema de la siguiente manera:

• Diseñe la lógica primero en la interfaz de usuario. Un inicio de sesión fallido devuelve el estado de error inmediatamente, pero hay un retraso antes de que la IU se reinicie para permitir un intento de inicio de sesión adicional. Esto no es para hacer cumplir la regla, sino para garantizar que un usuario de buen comportamiento nunca vea un mensaje de error.

• Imponga la lógica en el backend devolviendo inmediatamente un estado de error para cualquier intento de inicio de sesión durante el período de "enfriamiento". Ni siquiera compruebe si la contraseña es correcta, simplemente falle de inmediato y consuma la menor cantidad de recursos posible.

• Para probar si un intento de inicio de sesión está permitido todavía, la mejor solución es usar algo liviano, como memcached. Por ejemplo, después de un intento fallido con un nombre de usuario determinado, almacenar en memcached el tiempo que expira el período de recuperación. Luego, cuando ingrese nuevos intentos de contraseña, verifique la entrada en memcached para ver si el período de enfriamiento aún está arriba.

• Implemente la misma lógica por IP, no solo por nombre de usuario. No debería poder adivinar miles de contraseñas por segundo simplemente rotando los nombres de usuario.

• Implementar un retroceso exponencial. Esto es un poco de crédito adicional, pero 2 intentos en 1 segundo no es un gran problema, pero 50 intentos en 5 minutos es un gran problema. Esto puede ser un poco más difícil de diseñar, pero los fallos repetidos deberían provocar tiempos de reinicio más largos. Esto podría ser tan simple como mantener un contador de fallas (nuevamente, en memcached) y calcular el próximo enfriamiento como una función de ese contador. Sin embargo, la lógica por IP debería ser un poco diferente, ya que no quieres que el atacante pueda restablecer su contador simplemente enviando las credenciales de un usuario conocido.

Desea que su servidor haga el menor trabajo posible para evitar hacer DoSing. El bloqueo de la cuenta es ideal para los usuarios.

si cuenta (autenticaciones fallidas para el nombre de usuario U) > Umbral luego demanda resuelta CAPTCHA

si cuenta (autenticaciones fallidas para la contraseña P) > Umbral luego demanda resuelta CAPTCHA

si no le gusta CAPTCHA, solicite Prueba de trabajo

(haga que el cliente calcule los factores primos de un gran número real)

Una demora tradicional mitigaría los ataques basados en el navegador web, por ejemplo, si alguien usa phantomjs para automatizar los intentos de inicio de sesión, la demora normal (en su caso, "más de un segundo") sería suficiente para evitar que alguien intente brutalmente forzar una contraseña , sólo toma demasiado tiempo.

Sin embargo, la mayoría de los ataques de fuerza bruta no se ejecutan en navegadores web, sino en entornos de script donde pueden emitir varias solicitudes al mismo tiempo.

La forma en que lo implementaría es teniendo un retraso intencional en el lado del servidor después de un inicio de sesión fallido, más un mecanismo de regulación (algo como this ) y un mensaje de inicio de sesión o control giratorio que informa al usuario de que se están comprobando las credenciales (nadie quiere una página en blanco para una recarga o un sistema que parece fallar para < em> un largo tiempo)