¿Es la fuerza bruta una amenaza probable incluso si habilita CAPTCHA y los inicios de sesión con límite de velocidad?

Las protecciones que describe son buenas que debería tener en cuenta, pero aún puede haber debilidades:

• Muchos CAPTCHAS pueden ser resueltos por robots, o puede pagar fácilmente a las personas para que los resuelvan en masa para usted (hay compañías que venden ese servicio).
• El bloqueo de la cuenta es una buena idea, pero si lo hace por IP, alguien con acceso a una botnet podría volver a intentar iniciar sesión en una sola cuenta desde diferentes IP: s hasta que entren.
• La fuerza bruta sin conexión sigue siendo un problema si su base de datos se filtra. Si el atacante tiene acceso al hash de contraseña, puede intentar todo lo que quiera en su propio sistema. Es por eso que deberías usar un buen hashing.

Tal vez.

depende de cómo se define la "fuerza bruta".

Un bloqueo después de X intentos incorrectos es excelente para proteger una cuenta donde un atacante persigue un solo objetivo.

Hay otro escenario en el que el atacante ha elegido algunas contraseñas comunes "contraseña, contraseña123, etc." Y en lugar de atacar a un solo usuario, prueban sus 4 contraseñas comunes en cada cuenta que conocen en su sistema.

User: Jim
PW: password, password123, letmein, secret

User: Bob
PW: password, password123, letmein, secret

User: Alice
PW: password, password123, letmein, secret

Esto es más común en los escenarios donde los atacantes buscan cosechar las credenciales para revenderlas en la red oscura, o hacer movimientos laterales a otros servicios donde las contraseñas pueden haber sido reutilizadas.

Le sugiero que agregue algo en su lugar para contar la tasa de inicios de sesión no válidos en general, en lugar de solo por cuenta o nivel de IP.

Es una amenaza en un sentido diferente. Si bloquea cuentas durante 15 minutos después de 5 intentos fallidos, entonces efectivamente ha incorporado un mecanismo DoS.

Supongamos que realmente no quiero entrar, pero estoy bien con solo causar el caos, no hay problema. Solo haga unos pocos miles de inicios de sesión por segundo con nombres de usuario aleatorios. Oye, ni siquiera me molestaré en hacer el CAPTCHA, a quién le importa. Todo lo que quiero es fallar y bloquear .

Una estrategia mejor que una cantidad fija de tiempo después de un número fijo de fallas puede ser el crecimiento cuadrático (o exponencial). Algunos enrutadores AVM hacen eso. Primer fallo en el inicio de sesión, tiene un bloqueo de 15 segundos, el siguiente es 30, etc. Esto es mucho menos problemático para los usuarios legítimos y mucho más para los atacantes.
Para hacer más difícil el DoS, necesitaría un tipo de receta que incluya la dirección IP y el nombre de la cuenta, que limita el retraso máximo por par de cuenta-IP a un valor tolerable. De lo contrario, un usuario legítimo aún podría ser DoSed de forma fácil e indefinida. Sin embargo, el crecimiento exponencial se relaciona mejor con el problema del "número infinito de intentos".

En realidad, encontrar un par de nombre de usuario y contraseña en línea por fuerza bruta es bueno, asumiendo que las personas no son estúpidas, prácticamente sin esperanza. Desafortunadamente, las personas son estúpidas, por lo que no puedes asumir que no tendrán una de las diez contraseñas más estúpidas, y debes asumir que es factible. Entonces, sí, también hay un poco de amenaza. En particular porque si bien puede ser difícil apuntar a un usuario en un servidor, en un sistema de control basado únicamente en el nombre de usuario, puede apuntar a mil usuarios en ese mismo servidor en paralelo sin problemas (cada puntuación solo un solo fallo!) y puedes hacerlo en mil servidores en paralelo. Y, en realidad, no le cuesta nada mantener este script durante semanas (meses, años ...), reintentar cada 15-20 minutos.

Entonces, mientras que para la cuenta individual , sus posibilidades como atacante son muy pequeñas, ya que los números se suman a, bueno, virtualmente infinito está obligado a golpear a alguien, en algún lugar , eventualmente, es inevitable. Como de lo contrario es trivial intentar mil usuarios en paralelo, debe quedar claro que también debe tener en cuenta las direcciones IP en sus cálculos. Aun así, no ofrece una protección del 100% contra una botnet con unos pocos miles de bots, pero sí hace que el ataque sea un poco menos efectivo, lo que requiere más trabajo y administración. Más trabajo es bueno.

No puedes ganar la carrera una vez que eres un objetivo serio, pero cuanto más difícil sea el trabajo de un atacante, más probable es que el atacante elija a alguien más (que es un objetivo más fácil) para comenzar. Es muy parecido a bloquear la puerta de su casa en lugar de dejarla abierta. Un ladrón puede romper fácilmente su ventana, y finalmente no hay nada que pueda hacer para evitar que alguien entre. Pero dada la opción de una puerta abierta en la casa del vecino y tener que romper la ventana, es probable que elija la forma más fácil. Menos gastos, mismo beneficio.

Sí, sigue siendo una amenaza, porque:

• Los CAPTCHA se están acercando muy rápidamente al punto del teatro de seguridad. Existen múltiples servicios que pueden romperlos (por un precio), y cada vez es más difícil encontrar problemas que puedan ser resueltos de forma trivial por un humano pero no por una computadora.
• Los intentos de fuerza bruta contra un solo usuario no son los únicos ataques potenciales con los que tiene que lidiar. No es raro que los ataques intenten el mismo conjunto de contraseñas en una lista de nombres de cuenta conocidos. Tampoco es demasiado inusual que ciertos servicios tengan un puñado de nombres de usuario conocidos (por ejemplo, SSH) para ver los ataques de mapeo de usuarios.
• A menos que esté aplicando algún tipo de verificación de la calidad de la contraseña, es bastante probable que un intento de fuerza bruta no necesite suficientes intentos por 5 intentos cada 15 minutos para ralentizarlo lo suficiente.

Ideas para mejorar lo que has propuesto:

• Como se mencionó anteriormente, imponer la calidad de la contraseña. En una situación ideal, permita que funcionen cosas como el método de generación de contraseñas de XKCD (consulte XKCD # 936 para obtener información sobre eso), y mejor sin embargo, asegúrese de que se acepte cualquier carácter válido de Unicode.
• Devuelva exactamente el código de error uno para un error de autenticación debido a credenciales no válidas, en lugar de tener diferentes para nombres de usuario no válidos y contraseñas no válidas. Esto es realmente importante, ya que protege contra los ataques de mapeo de usuarios.
• Proporcionar soporte MFA. En realidad, esto no es difícil de hacer correctamente si te tomas un tiempo para configurarlo. Los métodos TOTP MFA (como lo que proporcionan la aplicación Google Authenticator y el sistema MFA de Steam) son generalmente bastante fáciles de usar y son razonablemente seguros. U2F también es bastante seguro, pero requiere más trabajo para configurar. En cualquier caso, si va de esta manera, permita múltiples métodos de AMF (idealmente una mezcla de diferentes tipos). Evite cualquier cosa que requiera enviar los códigos de inicio de sesión por correo electrónico (no es absolutamente seguro) o SMS (es mejor que el correo electrónico, pero puede tener un retraso muy largo antes de que se reciba el código). Todos los usuarios que habilitan MFA están protegidos funcionalmente de la mayoría de los ataques de fuerza bruta.
• No solo use un arreglo de bloqueo estático. En su lugar, use un enfoque adaptable, donde el tiempo que la cuenta permanece bloqueada se basa en cuántas veces se ha bloqueado recientemente. Un sistema de escalamiento exponencial simple con un límite superior en el tiempo de bloqueo funcionará bien. Por ejemplo, haga que el tiempo sea igual a 15 * 2^n minutos con un límite de 2 horas, donde n es el número de bloqueos anteriores en las últimas 24 horas (el primer intento es un bloqueo de 15 minutos, el segundo es 30, el tercero es 60, cuarto y subsiguientes son 120).

Hay ataques de fuerza bruta de baja velocidad, diseñados específicamente para entrar en cuentas con tiempos de espera o bloqueos.

Si el atacante puede averiguar tus umbrales (que puede ejecutar por prueba), puede escribir un bot para mantenerse justo por debajo de ese umbral.

Por supuesto, esto limita la cantidad de combinaciones que puede probar en un período de tiempo determinado, por lo que este tipo de ataques a menudo se ejecutan durante meses o años y es poco probable que comprometan las cuentas con contraseñas razonablemente largas.

Entonces, en combinación con una política de contraseña sensata (ese es un tema diferente, aquí solo diré esa complejidad! = seguridad y longitud > complejidad) y una implementación sólida de su sistema descrito, puede reducir la probabilidad de Un compromiso considerablemente. En la mayoría de los casos, basta con que el riesgo restante se encuentre dentro de su límite de aceptación de riesgos.

Los inicios de sesión con límite de velocidad, el bloqueo de cuenta, etc. son buenos para detener cualquier ataque de fuerza bruta económicamente viable contra una pantalla de inicio de sesión, pero no es necesariamente así como se realiza el ataque.

Muy a menudo las cuentas se ven comprometidas porque el ataque de fuerza bruta no se realiza contra la propia pantalla de inicio de sesión (que es limitativa) sino contra una copia de los datos. Si un atacante puede obtener acceso a los datos a través de un servidor comprometido o por algún otro medio, el ataque de fuerza bruta realmente consiste en descargar las cuentas y contraseñas, y luego romper el cifrado en una máquina mucho más poderosa.

La fuerza bruta no necesita usar mucha "fuerza". La fuerza bruta puede durar días y ser una caída pequeña, pero persistente, gota tras gota. Consideraría que el captcha no es un problema para cualquier atacante determinado.

Incluso con sus restricciones, usted dio a entender que estos límites solo se aplican a una sola cuenta. Así que si sé que hay varias cuentas, aún puedo automatizar el proceso para seguir intentándolo.

No podré forzar bruscamente todo el espacio de teclas posible con sus restricciones, pero podré forzar las 1000 contraseñas principales por cuenta en muy poco más de 2 días.

Dado que una lista de las 1000 contraseñas principales probablemente cubriría un porcentaje razonable de sus usuarios, debería poder acceder a su sistema muy pronto.

Entonces, ¿puedes defenderte contra esto?

¿Limitar el juicio por IP? - > Vector para evitarlo: Botnets / VPN

Entonces, ¿vamos a agregar "viajes imposibles" a la lista? (El usuario inicia sesión desde Alemania y EE. UU. En un minuto)

Entonces, ¿qué hay de la misma IP para varios usuarios?

Una cosa a considerar es el valor del recurso que intenta proteger y los pasos adicionales que desea tomar para protegerlo. Otra adición bastante segura a la fuerza de su sistema es un segundo factor. Pero esto puede causar un costo adicional para usted, dependiendo de lo que use y de cuántas autenticaciones necesite hacer. Por ejemplo, como servicio independiente, Azure cobrará 1,4 $ por 10 autenticaciones. O puede utilizar algún tipo de servicio gratuito o un sistema "Grid" con datos únicos por usuario.

  

¿La fuerza bruta sigue siendo una amenaza probable?

"Probable" depende de qué tan sabroso sea tu objetivo. Si eres un objetivo deseable, entonces sí, son una amenaza.

Si bien un tiempo de espera con un límite de velocidad y un bloqueo se hará cargo de la fuerza bruta, ya que solo obtendrían X intentos en Y minutos, es un gran problema ya que permite que los atacantes externos bloqueen a sus usuarios casi sin esfuerzo. / p>

En este caso, puede elegir entre amenazas. Está decidiendo que a cambio de proteger cuentas individuales, un atacante puede bloquear a los usuarios. Es un ataque diferente al robo / cambio de datos, pero sigue siendo un ataque.

Una mejor solución sería requerir contraseñas seguras y autenticación de dos factores y no tener bloqueo.

Si haces ambas cosas, tus cuentas estarán razonablemente seguras y tus usuarios no serán bloqueados.

La vulnerabilidad aquí se reduce significativamente, ya que el atacante tendrá que robar y descifrar la base de datos de contraseñas y los secretos de 2FA para obtener acceso, pero en el momento en que tengan la profundidad suficiente para hacerlo, no necesitan al usuario. cuentas más.

Esto realmente depende de lo que estés protegiendo. Si se trata de un blog de Wordpress y los usuarios no pueden comentar tu última publicación, no es un gran problema. Si su sitio contiene registros financieros, médicos o de seguridad, es un gran negocio.