mi prevención de fuerza bruta tiene desventajas importantes, ¿alguna idea?

Question

mi prevención de fuerza bruta tiene desventajas importantes, ¿alguna idea?

#1 de David Scholefield (2 votos)
#2 de dr01 (1 votos)

2

Actualmente estoy buscando la mejor manera de evitar los ataques de fuerza bruta en el portal web de mi software y se me ocurrió la siguiente idea:

3 intentos de inicio de sesión sin ningún desafío visual
después de 3 intentos fallidos, muestre Google reCaptcha
permite otros 3 intentos pero ahora tienes que hacer clic en el captcha cada vez
si los últimos 3 intentos fallaron nuevamente, bloquee la cuenta

Mi idea solo tiene grandes inconvenientes y espero que puedas dar un consejo:

¿Qué sucede si el nombre de usuario cambia en cada intento de inicio de sesión? cual ¿Puedo bloquear la cuenta después de 6 intentos?
¿Cómo debo registrar los 3 intentos fallidos (no depende de si son 3 intentos en una cuenta o un intento en 3 cuentas diferentes) antes de mostrar el captcha?
- IP? Pero, ¿qué pasa si muchas de las personas de la red de una empresa utilizan el software a la vez?
- ¿Agente de usuario del navegador? ¿Qué pasa si alguien que intenta el ataque de fuerza bruta simplemente cambia el agente de usuario en cada intento de inicio de sesión?
- ¿Cookies?

web-application authentication brute-force

pregunta 12dollar 12.10.2015 - 10:47

fuente

2 respuestas

Lea otras preguntas en las etiquetas web-application authentication brute-force

Generando un certificado SSL propio utilizando DSC emitido por una CA ¿Qué * en realidad * es una vulnerabilidad de los applets de Java?

score 2 · Answer 1

Detectar la fuerza bruta solo por el comportamiento del cliente del usuario es notoriamente difícil. Debido a ataques distribuidos, los ataques contra múltiples nombres de usuarios, etc., hacen que los patrones de tráfico sean difíciles de detectar.

Mi recomendación, y la solución que uso en casi todos mis sistemas, es insertar un retraso simple en el proceso en el punto de falla, por lo que si un usuario se autentica correctamente, simplemente funciona normalmente pero para cada failure inserta una demora de 2 o 3 segundos antes de declarar la falla.

Esto no causa ningún problema, tanto para los seres humanos como para los clientes con secuencias de comandos (como el acceso legítimo a las API, etc.), pero para los ataques de fuerza bruta, el proceso se reduce a una velocidad infasiblemente lenta incluso para cada uno de los posibles números de Subprocesos de fuerza bruta paralelos (siempre que las contraseñas sean complejas, por supuesto).

Además, la mayoría de los lenguajes del lado del servidor liberan la CPU para los comandos de "suspensión" y, por lo tanto, esto evita que esta solución particular cause un DOS basado en el tiempo de CPU (aunque los grupos de zócalos de conexión aún pueden ser un problema).

score 1 · Answer 2

Creo que tu enfoque es bastante bueno.

Algunas notas sobre su solución propuesta: un "intento fallido de inicio de sesión" puede considerarse como tal, por ejemplo, es el mismo nombre de usuario que se ha probado. Para protegerse contra los ataques de fuerza bruta, cuenta el número de intentos de inicio de sesión fallidos en un lapso de tiempo, por ejemplo. en su caso, 15 minutos para 3 intentos de inicio de sesión sería un buen valor. Esto activaría el segundo nivel, es decir, mostrar el captcha.

También es una excelente solución introducir demoras después de cada intento de inicio de sesión (según lo propuesto por @DavidScholefield), y puede usarlo junto con su método. Puedes usar:

un retraso fijo de 2-3 segundos antes de mostrarle al usuario el mensaje sobre cualquier intento fallido de inicio de sesión, incluso si es el primero
o puede usar un retraso creciente, que puede ser
- ya sea lineal (por ejemplo, 3 segundos, 6 segundos, 9 segundos, 12 segundos, ...)
- o exponencial (por ejemplo, 2 segundos, 4 segundos, 8 segundos, 16 segundos, ...)

La belleza de la demora fija es que no tiene que registrar nada.
En el caso de la demora creciente, debe iniciar sesión en el nombre de usuario que falló en el inicio de sesión (para evitar el uso de fuerza bruta en un usuario) y también la dirección IP que falló en el inicio de sesión (para evitar que una dirección IP obligue a todos los usuarios de su sistema, un intento a la vez).

Las IP superpuestas de la misma empresa no son un problema, ya que los usuarios deben usar su propia cuenta. (Si no lo hacen, y comparten las credenciales de la cuenta, ese es su problema).