Mejores prácticas en autenticación de seguridad de aplicaciones web para evitar ataques de fuerza bruta

Una forma relativamente fácil de mitigar los ataques de fuerza bruta es retrasar el tiempo mínimo entre intentos. La primera vez que su usuario ingresa las credenciales incorrectas, lo deja esperar 1 segundo antes de que pueda volver a intentarlo. La segunda vez, lo dejas esperar 2 segundos. La tercera vez, le haces esperar 4 segundos. 4ª vez, 8 segundos, y así sucesivamente. También basa esto en el nombre de usuario que se utiliza para autenticar, no en ninguna dirección IP. Si no ha habido un intento en los últimos 5 minutos (o si el usuario se autenticó correctamente), reinicie el contador.

El resultado es que un usuario que hace un error tipográfico en su contraseña no se ve afectado las primeras veces, pero los forzados brutos llegarán muy rápidamente a un punto en el que el forzamiento de los brutos ya no es viable.

Además de prevenir su aplicación web contra ataques de fuerza bruta, también debe garantizar prácticas de protección de contraseña estándar como hashing y amp; salado (preferiblemente con PBKDF2 o bcrypt), restablecimiento seguro de contraseñas y mitigación contra la enumeración de nombres de usuario. Pero supongo que, como publicas aquí, ya lo sabes.

Un buen compromiso entre la experiencia del usuario y la seguridad sería tener captchas basados en IP que se activen después de algunos inicios de sesión fallidos desde una IP particular, independientemente del nombre de usuario.

• Este enfoque no es vulnerable a los ataques DoS contra un solo usuario al forzar bruscamente su cuenta hasta que el tiempo de espera llega a varias horas / días e impide que el propietario legítimo de la cuenta inicie sesión.

• El número de personas atrapadas detrás de un NAT no es tan alto, y es mejor degradar un poco su experiencia con un captcha en lugar de proporcionarle a los atacantes la posibilidad de hacer una cuenta completa y bloquear a sus legítimos propietarios.

• Depende de para qué es tu aplicación y cuánto dura la sesión, pero si es algo como Stack Exchange, la gente generalmente no inicia y cierra sesión con frecuencia.

En cuanto a sus preocupaciones sobre el uso de sesiones para rastrear inicios de sesión incorrectos, tiene razón, no tiene sentido ya que funcionará para usuarios legítimos, pero un atacante ni siquiera se molestará en almacenar las cookies de sesión, lo que significa que en cada intento, obtenga una nueva sesión y nuevos intentos de inicio de sesión sin captcha.

Para el cambio de IP, sí, eso es un problema, pero una IP sigue siendo un costo para el atacante, eventualmente se quedará sin proxy y / o máquinas comprometidas en su botnet, y tendrá que comprar Más. También debe solicitar siempre un captcha si la IP está en una base de datos proxy abierta (busque una en Google) o en la lista de nodos de salida Tor; de esa manera, un atacante no podrá usar estas soluciones "gratuitas" y tendrá que alquilar una red de bots o algunos proxies "premium" que aún no están en las listas negras.

He estado investigando para mitigar los ataques de fuerza bruta y encontré este post. Recientemente implementé el siguiente enfoque:

En un período de 24 horas: en 20 o más intentos de autenticación fallidos para una única dirección IP, requerimos captcha para cada intento posterior. En 100 intentos fallidos, hacemos solicitudes de agujero negro, pero no damos indicios de que la solicitud haya sido bloqueada, solo seguimos devolviendo el mensaje de error estándar.

Para nosotros esto es razonable ya que no nos preocupan las grandes cantidades de personas que inician sesión desde la misma IP y creemos que nuestros umbrales son lo suficientemente altos como para que un usuario normal no se vea afectado. Es trivial enviar una alerta con 100 fallos o si aparece un nombre de usuario en varias direcciones IP.

Registramos todo en una base de datos. Aceptamos que una red de bots podría usar una gran cantidad de direcciones IP, sin embargo, registramos el nombre de usuario con el que no se pudo autenticar una dirección IP. Esta tabla generalmente se verifica una vez al día, por lo que existe la posibilidad de que identifiquemos un ataque de fuerza bruta a gran escala dirigido a un solo usuario.

Recientemente también mejoramos nuestros requisitos de contraseña para aumentar la longitud y la complejidad de los caracteres y no permitir las contraseñas en varios diccionarios de contraseñas. Nuestra página de inicio de sesión no está indexada en Google (no en robots.txt, use la etiqueta meta robots ya que los atacantes pueden revisar su robots.txt para ver si hay páginas interesantes). Finalmente, las cuentas de administrador requieren autenticación de dos factores.

Aún así, aceptamos el riesgo de que un ataque de fuerza bruta sea posible.