¿Por qué sigue siendo necesario bloquear los ataques de fuerza bruta cuando la verificación de hash de las contraseñas requiere un trabajo significativo?

2

Para los controles de autenticación, Owasp brinda consejos para prevenir ataques de fuerza bruta mediante bloqueo de la cuenta , y veo este tipo de consejos en varios lugares (bloqueo por IP de origen después de inicios de sesión fallidos, bloqueo por cuenta ...).

¿Por qué?

Quiero decir, dos casos aquí:

  • o bien almacena de forma segura sus contraseñas en la base de datos con una verificación costosa (bcrypt, argon2, ...): en este caso, se supone que sus contraseñas resisten el ataque sin conexión, cuando el atacante tiene acceso de lectura directa al base de datos. Y creo que lo harán: si la verificación de la contraseña toma del lado del servidor ~ 0.05s con un hardware decente e impone una longitud de contraseña de 7 caracteres Y prohibe la contraseña común (incluida en una lista potencialmente grande), tomará en promedio 0.05 * 62^7 / (2*3600*24*365) = 2 800 years para descifrar cada contraseña (asumiendo que los usuarios eligieron contraseñas de 7 caracteres en [a-zA-Z0-7] ). A menos que su modelo de amenaza implique que un atacante tenga un poder de computación realmente grande, lo encuentro suficiente. Y el ataque en línea (la fuerza bruta que usa el formulario de inicio de sesión) es más lento que el ataque sin conexión: ¿sigue siendo necesario bloquear al atacante si sus intentos de fuerza bruta fracasan durante bastante tiempo? Y sí, el intento de fuerza bruta será un tipo de (D) DoS, pero esto debe ser mitigado por técnicas generales anti- (D) Dos que no son específicas de los formularios de inicio de sesión.

  • O bien, no almacena su contraseña de forma segura (hashes de procesamiento rápido, sin sal, sin hashes ...): este es un problema y primero debe considerar el almacenamiento seguro de las contraseñas. Y si no puede (legados de software ...), simplemente agregando un retraso de 200 ms a cada verificación de contraseña se obtiene una protección similar en el formulario de inicio de sesión (pero no en el caso de la pérdida de la base de datos / ataque sin conexión), y es mucho más simple para implementar.

En ninguna de estas 2 alternativas veo que el bloqueo de fuerza bruta intenta una buena solución. Agrega complejidad y, potencialmente, crea vulnerabilidades DoS.

    
pregunta SamuelBF 09.11.2018 - 13:12
fuente

2 respuestas

5

El almacenamiento seguro de contraseñas por sí solo no ayuda a que Brute fuerce contraseñas triviales. Si todo lo que el atacante tiene que hacer es intentar 100 contraseñas para llegar a la cuenta de los usuarios, la verificación lenta de la contraseña no es un problema real. Además, la verificación de la contraseña no puede ser demasiado lenta porque, de lo contrario, se puede crear un DOS en el sistema simplemente intentando iniciar sesión.

Con respecto a su ejemplo: si la verificación de una contraseña tarda 0.05 segundos, el sistema solo puede verificar el inicio de sesión de 20 usuarios en un solo segundo. Para muchos casos de uso esto es demasiado lento. Por otro lado, el atacante solo necesita 5 segundos para forzar las contraseñas de fuerza bruta 100 y al mismo tiempo hace que el sistema sea inutilizable para otros (es decir, DOS).

Si, en cambio, la verificación de la contraseña toma solo 0.01 segundos, pero hay un límite de solo 3 intentos en 30 segundos para una sola cuenta de usuario, el atacante necesitará 1000 segundos para probar 100 contraseñas y al mismo tiempo el sistema puede manejar Otros usuarios sin problema.

Aparte de eso, el hash de contraseña común no está destinado a tratar con ataques de fuerza bruta contra una sola cuenta. En cambio, la complejidad de la salazón y el picadillo están destinados a hacer que sea imposible descifrar las contraseñas en masa.

    
respondido por el Steffen Ullrich 09.11.2018 - 14:00
fuente
0

El hash es razonablemente rápido, por lo que es perfectamente posible capturar algunos miles de contraseñas por segundo. Por supuesto, hay hashes que están diseñados para ser muy lentos y hash que están diseñados para ser seguros y eficientes. Sin embargo, si elige un hash que es demasiado lento y tiene muchos usuarios, puede detener intentos de inicio de sesión legítimos porque su servidor no puede manejar la carga.

  

simplemente agregando un retraso de 200 ms a cada verificación de contraseña se logra una protección similar en el formulario de inicio de sesión

Sí, pero un retraso suele ser un reposo, lo que significa que el proceso de ejecución (o la fibra) se bloquea durante 200 ms y, si realiza mil solicitudes de fuerza bruta por segundo, tendrá miles de procesos suspendidos o mil Fibras colgantes - ninguna de las cuales es ideal. Además, un retraso no hace prácticamente nada contra las solicitudes de fuerza bruta, ya que las solicitudes se producen en paralelo. Si puedo probar 1000 contraseñas, entonces no me importa ese retraso de 200 ms porque solo retrasará la primera respuesta. Si lanzas mil rocas por un acantilado y toman 200 ms para golpear el suelo, 200 ms no limita la cantidad de rocas que puedes lanzar, solo aumenta la demora hasta que la primera roca toca el suelo.

    
respondido por el mroman 10.11.2018 - 11:33
fuente

Lea otras preguntas en las etiquetas