¿Los ataques de adivinación de contraseñas son una amenaza real?

1

Hay un montón de preguntas, respuestas, artículos, artículos, caricaturas, etc. sobre cómo elegir una contraseña de tal manera que sea difícil de adivinar o descifrar con un ataque basado en un diccionario.

No entiendo por qué un sistema me permitiría intentar ese tipo de ataque en primer lugar, así que me pregunto qué es lo que me falta de ese tipo de ataque, o cualquier otro tipo de ataque que Implica probar millones de contraseñas diferentes hasta que una funcione.

¿Por qué alguien querría que un sistema permitiera cientos o incluso millones de intentos de inicio de sesión con el mismo nombre de usuario y contraseñas diferentes en un tiempo relativamente corto? Agradezco que me den un poco de holgura si no puedo recordar mi contraseña o si pierdo la clave correcta cuando la escribo, pero no necesito, ni quiero, que se me permita probar y fallar 100 veces con el mismo nombre de usuario y a toda velocidad.

En otras palabras, ¿qué tan difícil sería diseñar un sistema de tal manera que después de un intento fallido de inicio de sesión no se pueda realizar el siguiente antes de que transcurra un tiempo que sea proporcional al número de inicios de sesión fallidos para ese nombre de usuario? Estoy pensando en décimas de segundos o algo así como un segundo más por cada intento fallido, lo que no afectaría los intentos de un usuario real, pero a mi entender limitaría seriamente la posibilidad de ataques de diccionario.

En general, excepto por algunos nichos que puedo imaginar, ¿no sería relativamente trivial e inofensivo para la gran mayoría de los sistemas hacer que este tipo de ataques no sean factibles?

    
pregunta SantiBailors 03.02.2016 - 13:14
fuente

2 respuestas

6

Depende contra lo que estés defendiendo, realmente.

  1. Al intentar iniciar sesión en una aplicación web, los intentos deberían estar restringidos de alguna manera. La restricción de la velocidad de IP es un buen comienzo, la restricción de la tasa de nivel de nombre de usuario es mejor, combinar los dos es incluso mejor. Sin embargo, imagine que tengo una larga lista de nombres de usuario y contraseñas de una violación anterior no relacionada. Si tengo acceso a una red de bots (vaya a la red oscura y navegue por unos minutos, puede comprar el acceso por un tiempo) y un poco de conocimientos de programación, puedo configurar fácilmente una situación en la que cada dirección IP intenta un solo nombre de usuario con una sola contraseña, luego espera un rato antes de intentar un nombre de usuario y contraseña diferentes. Teniendo en cuenta las suficientes máquinas, estaría bastante seguro de tener éxito con un puñado de contraseñas comunes y una lista bastante grande de nombres de usuarios.

    Si las contraseñas son todas fuertes, sin embargo, me llevará mucho más tiempo, lo que significa que hay una mayor probabilidad de que alguien note el ataque.

  2. Intentando romper cuentas después de una violación. En este caso, se omite cualquier sistema que tenga implementado para restringir la velocidad de ataque. Tengo una copia de los hashes de contraseñas, por lo que puedo incluirlos en mi equipo de descifrado de contraseñas y esperar un rato. Las contraseñas comunes serán de nuevo las primeras en romper, y las realmente fuertes tardan años (son grandes edades. Piense en las edades geológicas, en lugar de esperar las edades de entrega de pizza).

    En este caso, no me importan tus restricciones. Es posible que haya obtenido los datos de la violación sin que usted se dé cuenta, en cuyo caso, simplemente puedo iniciar sesión con las contraseñas que encuentro y borrar todo lo que tenga valor en esas cuentas. O puede haber descubierto que obtuve sus datos, en cuyo caso estoy compitiendo contra los legítimos propietarios para iniciar sesión primero. De cualquier manera, solo me toma un intento intentar entrar si lo voy a hacer.

En el caso 1, agrega complejidad al ataque, pero también agrega complejidad al método de autenticación. Lamentablemente, la complejidad en el código tiende a aumentar la cantidad de problemas, por lo que querrá estar seguro de que no tuvo efectos secundarios no deseados, como los ataques de tiempo o el potencial DoS (imagine que tengo una IP compartida, como un proveedor móvil) podría usar, y hago que se bloquee durante un período de uso máximo).

En el caso 2, es irrelevante. No me importa Nunca lo veas.

Como con todo en seguridad, es una cuestión de equilibrar los riesgos. Si tiene cuentas de alto valor, vale la pena poner más aros para saltar, pero debería poder permitirse un proceso de prueba muy estricto. Si tiene cuentas de bajo valor, podría ser más seguro vivir con ese riesgo, para evitar que funcionen otros vectores de ataque.

    
respondido por el Matthew 03.02.2016 - 13:46
fuente
0

El sistema tiene la culpa de una infracción en el sistema. Si permiten millones de inicios de sesión por segundo, y un usuario no autorizado obtuvo acceso, entonces IMO está en ellos. Si el sistema decide no cifrar los datos privados de las personas (mirando su OPM), entonces esta culpa está en el sistema. Usando sistemas operativos y software obsoletos; Esa culpa está en el sistema. Creo que entiendes el punto.

Sin embargo, el usuario tiene la responsabilidad de proteger su cuenta de una infracción. La contraseña proporcionada es muy probablemente utilizada para derivar una clave que cifra y protege su información privada. Si un sistema ha protegido adecuadamente sus datos, entonces se protege cualquier información de cuenta que se tome. Si un usuario elige una contraseña incorrecta que le permite al atacante obtener acceso a sus datos privados que no pueden ser culpados en el sistema.

Los sistemas tienen vulnerabilidades. No importa lo avanzado o bien protegido. Pueden hacer todo lo posible para mitigar las infracciones, pero culparles cuando se roban una cuenta porque un usuario decidió usar "contraseña" es falso.

    
respondido por el RoraΖ 03.02.2016 - 14:59
fuente

Lea otras preguntas en las etiquetas