¿Prevención adecuada de ataques de fuerza bruta distribuidos?

1

¿Cuáles son las buenas maneras de prevenir los ataques de fuerza bruta distribuida en mi sitio web?

Yo pienso (no estoy seguro. ¡si alguien me puede asegurar, gracias !), mi sitio está protegido contra los ataques normales de fuerza bruta, ya que estoy usando el siguiente patrón para acelerar continuamente. intentos de inicio de sesión para un nombre de usuario único :

X = Failed Login Attempts
Y = Time, since the last login attempt, for which next login attempt will not be accepted (in minutes)

if X is a multiple of 5
Y = 2^(X/5)

Esto aumenta el retraso de tiempo en un exponente de 2 por cada 5 intentos de inicio de sesión incorrectos.

Luego pensé: ¿qué pasa si alguien intenta distribuir este ataque de fuerza bruta en múltiples nombres de usuario / cuentas para una misma contraseña ? O.O

Mi primer instinto fue buscar en Internet prácticas comunes. Busqué y encontré diferentes soluciones. Cada solución ha tenido sus propias desventajas, mientras que la mayoría de ellas eran demasiado complicadas.

Y luego whaaam! Esta idea descabellada cruzó mi mente:

It doesn't matter if you provide wrong or right credentials, the login script will sleep for 1 second while verifying your credentials.

Si utilizara este método, tomaría aproximadamente 14 horas probar una contraseña en cuentas de 50k o viceversa y, por lo tanto, hacer que la fuerza bruta sea poco práctica .

Desde que esta es mi primera aplicación web , estoy poco seguro de que este método sea correcto para usar. No estoy seguro de si causará demasiada carga del servidor o si es incluso seguro. ¿Este método ofrece una buena compensación entre el tiempo y el costo de los recursos, en comparación con la seguridad agregada?

Si alguien puede ayudarme a averiguar si este es el método correcto y ayudarme a mejorarlo y / o sugerir un método práctico (en caso de que esto no esté bien), quizás puedo ofrecerle una cookie adicional si alguna vez nos encontramos?

    
pregunta ashu 02.01.2015 - 17:26
fuente

3 respuestas

0
  

Si proporciona credenciales incorrectas o correctas, el script de inicio de sesión se suspenderá durante 1 segundo mientras verifica sus credenciales

Esto no sería efectivo a menos que esta suspensión se ejecutara en subprocesos, es decir, esto no detendría un ataque paralelo donde un atacante hace múltiples conexiones y ejecuta intentos de inicio de sesión simultáneos.

Si hiciera estos hilos de retardo, entonces estaría introduciendo un punto de estrangulamiento en su aplicación. Supongamos que el 1% de sus usuarios intentaron iniciar sesión al mismo tiempo, el último usuario tendría que esperar 500 segundos para que se complete su inicio de sesión.

La reducción de toda la aplicación no es una buena idea, ya que está creando una Denegación de Servicio (DoS) o un servicio reducido para sus usuarios reales.

  

¿Qué sucede si alguien intenta distribuir este ataque de fuerza bruta en varios nombres de usuario / cuentas para una misma contraseña?

La forma de evitar esto es hacer que su aplicación sea segura contra el nombre de usuario Enumeration . Las formas comunes en que los atacantes pueden enumerar los nombres de usuario son:

  • Después de un inicio de sesión incorrecto, si la página de inicio de sesión muestra que el nombre de usuario era incorrecto en lugar de la combinación de nombre de usuario / contraseña.
  • Si la página de registro de usuarios informa a los usuarios que ya se ha tomado un nombre de usuario.
  • Si la página de contraseña olvidada informa al usuario que no se encontró el nombre de usuario ingresado.
  • Si alguna URL está activa para usuarios válidos (por ejemplo, mi nombre de usuario es foo ) como www.example.com/user/foo .

Hay formas de evitar el registro de usuarios y las páginas de contraseña olvidadas que revelan si un nombre de usuario está registrado si el nombre de usuario es Basado en la dirección de correo electrónico. A veces, la posibilidad de enumerar los usuarios integrados en el diseño de la aplicación y evitar esto no es posible. p.ej. en una aplicación de correo web, todos los nombres de usuario son efectivamente públicos, ya que Bob anunciará que tienen la cuenta [email protected] si quieren que la gente les envíe un correo electrónico.

Además de hacer lo que está haciendo con conjeturas incorrectas a un usuario válido, también haría lo mismo para los inicios de sesión desde la misma IP. Esto acelerará la velocidad a la que las contraseñas pueden ser adivinadas horizontalmente contra diferentes usuarios. El retraso artificial podría comenzar después de 5 intentos fallidos desde la misma IP y el tiempo podría incrementarse gradualmente por intento.

Aunque eso no lo protege por completo de una red de bots, los intentos repetidos por separado tanto de IP como de nombre de usuario reducirán el riesgo de ataques de fuerza bruta.

Si desea mitigar prácticamente la amenaza de la fuerza bruta de la botnet, puede imponer un requisito para 2FA en todas las cuentas. Esto podría hacerse a través de un OTP enviado por SMS.

    
respondido por el SilverlightFox 02.01.2015 - 19:16
fuente
1

Aquí es un poco tarde, pero hay un montón de sugerencias aquí: enlace

Un problema con "tardaría aproximadamente 14 horas en probar una contraseña en cuentas de 50k". ¿Qué ocurre si su usuario legítimo intenta iniciar sesión después de que una red de bots haya ingresado 50k solicitudes y tenga que esperar las 14 horas? No feliz, presumiblemente.

    
respondido por el tim spear 24.11.2015 - 00:33
fuente
0

Su método puede ser algo efectivo, pero el defecto más grande y más obvio es que está desacelerando intencionalmente su aplicación. Puede ser tolerable si su base de usuarios se limitará a un par de amigos, pero si está abriendo esta aplicación al mundo, una desaceleración intencional sería completamente inaceptable desde el punto de vista de un ingeniero. Un segundo puede no parecer mucho, pero para los usuarios impacientes en estos días, cada segundo cuenta . Si agrega tiempo para que la página se descargue y se reproduzca realmente, su tiempo de carga para la página de inicio de sesión podría alcanzar fácilmente los 3-4 segundos o más, lo que puede parecer una eternidad cuando solo está allí esperando.

Además, solo sería efectivo si asume que cada usuario elegirá una contraseña segura, lo cual es muy poco probable que sea el caso. Es probable que una buena parte de ellos elija algo simple y común, como 123456, password1 o password123, y un atacante seguramente intentará esto primero. Si pasan 140 horas probando las 10 contraseñas principales en cada cuenta, no me sorprendería que el 5% de ellas se vea comprometida, lo que es un número considerable.

Una solución más limpia que muchos de los sitios principales ahora emplean es usar un Captcha (el texto distorsionado que debe leer y escribir). Después de aproximadamente 5 intentos de inicio de sesión incorrectos desde una sola dirección IP (independientemente de la cuenta), debe resolver un captcha para continuar intentando contraseñas. Esto es altamente efectivo para detener la fuerza bruta porque un guión de fuerza bruta no podrá resolver el captcha.

No se preocupe si no sabe cómo generar imágenes captcha: Google puede hacerlo por usted . Es muy fácil de usar; simplemente registre su sitio con el programa recaptcha (gratuito) de Google, copie un poco de código en su sitio web y Google hará el trabajo duro. Aquí hay un pequeño tutorial sobre cómo usarlo. Lo bueno es que últimamente lo han estado modernizando para que ahora pueda distinguir los bots de las personas sin requerir el texto distorsionado en absoluto .

Una solución alternativa es simplemente bloquear la dirección IP de los usuarios después de un cierto número de contraseñas incorrectas, independientemente de la cuenta, pero el inconveniente obvio de esto es que si alguien está forzado por una red pública (una biblioteca, por ejemplo, ), los usuarios legítimos podrían ser bloqueados. Personalmente, sigo pensando que la solución de captcha es la mejor, ya que es altamente efectiva para detener la fuerza bruta y tiene un impacto mínimo en los usuarios legítimos.

    
respondido por el tlng05 02.01.2015 - 18:35
fuente

Lea otras preguntas en las etiquetas