¿Cuáles son los inconvenientes de la limitación de solicitudes de inicio de sesión?

Navega tus respuestas
11

En una aplicación web, una forma de protegerse contra los ataques de adivinación de contraseñas es bloquear las cuentas después de un número determinado de inicios de sesión fallidos. Esto se puede hacer tanto en la dirección IP de origen como en el nombre de usuario.

Por ejemplo, la siguiente tabla muestra lo que sucede cuando se detectan intentos repetidos. El sistema está configurado para bloquear cuentas después de 3 inicios de sesión fallidos dentro de una ventana de 5 minutos, durante 5 minutos. 

IP             Time       Username           Creds Correct?  Message Given

203.0.113.1    10:00:00   [email protected]    N               Bad username or password
203.0.113.1    10:00:01   [email protected]    N               Bad username or password
203.0.113.1    10:00:02   [email protected]    N               Bad username or password
203.0.113.2    10:00:03   [email protected]    N               Bad username or password
203.0.113.1    10:00:04   [email protected] N               Login locked from your location
203.0.113.2    10:00:05   [email protected] Y               Welcome!
203.0.113.2    10:00:06   [email protected]    N               Account locked
203.0.113.2    10:00:07   [email protected]    Y               Welcome!
203.0.113.1    10:01:00   [email protected] Y               Login locked from your location
203.0.113.1    10:05:03   [email protected] Y               Welcome!

Los intentos de inicio de sesión solo cuentan cuando se validan las credenciales (el proceso es verificar el bloqueo antes de validar las credenciales; si están bloqueadas, las credenciales no se validan).

Como se puede ver en lo siguiente, un usuario malintencionado (en IP 203.0.113.3 ) puede bloquear una cuenta que causa una Denegación de Servicio al adivinar repetidamente la contraseña incorrecta a propósito: 

IP             Time       Username           Creds Correct?  Message Given

203.0.113.3    10:06:00   [email protected]    N               Bad username or password
203.0.113.3    10:06:01   [email protected]    N               Bad username or password
203.0.113.3    10:06:02   [email protected]    N               Bad username or password
203.0.113.3    10:06:03   [email protected]    N               Account locked
203.0.113.10   10:07:00   [email protected]    Y               Account locked
203.0.113.10   10:07:04   [email protected]    Y               Account locked
203.0.113.10   10:07:08   [email protected]    Y               Account locked
203.0.113.10   10:07:15   [email protected]    Y               Account locked
203.0.113.10   10:07:25   [email protected]    Y               Account locked

... impidiendo que el usuario real en 203.0.113.10 inicie sesión.

Una alternativa a esto es retrasar artificialmente la respuesta HTTP. Diga los primeros retrasos de inicio de sesión fallidos en 1 segundo, el segundo en 2 segundos, el tercero en 4 y así sucesivamente hasta un total de 16 segundos. Si su cuenta está siendo atacada, el usuario verá un círculo giratorio en su navegador mientras espera la respuesta HTTP a su solicitud de inicio de sesión.

¿Hay algún inconveniente a esto? Lo anterior ahora se vería como el siguiente (digamos que hay un retraso de 1 segundo como predeterminado, debido a las iteraciones de bcrypt): 

IP             Req Time   Resp Time Username           Creds Correct?  Message Given

203.0.113.3    10:06:00   10:06:01  [email protected]    N               Bad username or password
203.0.113.3    10:06:01   10:06:03  [email protected]    N               Bad username or password
203.0.113.3    10:06:03   10:06:08  [email protected]    N               Bad username or password
203.0.113.3    10:06:08   10:06:17  [email protected]    N               Bad username or password
203.0.113.10   10:06:18   10:06:35  [email protected]    Y               Welcome!

Tenga en cuenta que el retraso artificial (cuando está activo) es a través de subprocesos, lo que significa que el atacante no puede enviar solicitudes desde una única IP a una velocidad mayor. Un inicio de sesión de una IP diferente no está en cola, aunque seguirá experimentando cualquier retraso artificial generado por intentos incorrectos en el nombre de usuario.

Como puede ver, al usuario en 203.0.113.10 no se le niega el acceso; simplemente tiene que esperar 17 segundos para que se complete su inicio de sesión, mientras que el atacante tiene que retrasar su ataque. Por lo tanto, es eficaz en la prevención de ataques de adivinación de contraseñas.

Mi pregunta es ¿cuáles son los aspectos negativos de este enfoque y por qué no ve este tipo de enfoque con más frecuencia en lugar del bloqueo general que puede causar la denegación de servicio para los usuarios?

    
pregunta SilverlightFox 11.06.2015 - 16:07
fuente

4 respuestas

6

Para convertir tu escenario de ataque en 90 grados; considere al atacante que, en lugar de usar una lista de contraseñas contra un solo usuario, en lugar de usar una sola contraseña contra una lista de usuarios. Imagina que a I (como al atacante) no le importa a qué cuenta tengo acceso, simplemente quiero acceder a cualquier cuenta (por ejemplo, una cuenta bancaria). En lugar de intentar forzar a un solo usuario (lo cual es probable que falle), intento la misma contraseña (una común, que dice "CorrectHorseBatteryStaple") en contra de una lista de usuarios que he obtenido anteriormente (la mayoría de los sitios usan correo electrónico direcciones para nombres de usuario, que no son secretas de ninguna manera).

En este escenario, solo obtienes un solo golpe contra cada nombre de usuario, pero aún debes limitar mis intentos. Ninguna de las defensas propuestas protege contra este escenario tal como está.

Sus defensas deben enfocarse de otra manera, en lugar de limitar los intentos de inicio de sesión contra un nombre de usuario, debe limitar los intentos contra las direcciones IP. Creo que Google hace esto en este momento. Por ejemplo, si bloqueo su cuenta, aún debería poder iniciar sesión desde su dirección IP normal (I.E. diferente a los atacantes).

    
respondido por el Chris Murray 11.06.2015 - 17:20
fuente
3

Los inconvenientes que veo con este enfoque son:

  • Más complicado de implementar, especialmente en una plataforma escalable, entre hilos.
  • Puede que no sea efectivo en servidores con carga equilibrada.
  • Es posible que los usuarios tengan que ser pacientes.

Por las razones anteriores, no se implementa ampliamente.

    
respondido por el SilverlightFox 11.06.2015 - 16:07
fuente
2

No estoy seguro de por qué sería más difícil de implementar que bloquear la cuenta, o por qué el saldo de carga rs tendría algún efecto. Ambos enfoques requieren una coordinación centralizada sobre qué hacer (bloqueo vs retraso).

Creo que la razón principal es que es un comportamiento extraño, y hace que su sitio web parezca que está roto (no creo que esto sea simplemente paciencia). Los retrasos son comunes, y las personas están capacitadas para pensar que "el sitio web está roto" porque ese suele ser el caso en lugar de "oh, solo está retrasando mi inicio de sesión porque escribí la contraseña incorrecta", lo cual es muy inusual. En otras palabras, todos se capacitan sobre qué esperar del comportamiento de los sitios web según las normas de funcionamiento de los sitios web en general.

La otra razón es que las personas tienen un potencial limitado para reintentar las contraseñas diferentes. Si ha intentado iniciar sesión 10 veces en un sitio y ha fallado, ha olvidado su contraseña en ese momento y es poco probable que un intento 11, 12 y 13 sea de alguna utilidad. La mayoría de la gente se rendiría en quizás 5-7. Entonces, en ese momento es el tiempo de reinicio, y esperar otros 17 segundos no ayudará a nadie más que a un atacante.

    
respondido por el Steve Sether 11.06.2015 - 17:57
fuente
0

Su solución dependerá de la variable desde la que se accede al sistema de autorización (AD, ldap, ...).

¿Es la aplicación que menciona la única que usa el servicio de autenticación?

  • Si sí : la regulación funcionará bien. Es posible que haya usuarios sorprendidos por la lentitud de la aplicación (como la perciben ellos), pero esto puede no importarle mucho (su la aceleración debe ser fuertemente exponencial para que los primeros 3-5 intentos sean casi iguales, en cuanto al tiempo, luego coloque una curva de retardo pronunciada)

  • Si no : debe hacer la misma suposición para cada sistema de preocupación. Esto puede significar que algunas de las aplicaciones que no el control puede no tener el mecanismo de demora que usted menciona en su lugar. Esta También significa que debe tener un control estricto sobre qué aplicaciones use su mecanismo de autenticación (que puede no ser obvio si es expuesto a, digamos, todos sus entornos DMZ como un servicio DMZ)

En el caso de las aplicaciones, no me gusta la aceleración porque debe codificarla en el mecanismo de autenticación (que debería ser simple) o confiar en la limitación del firewall. Esto también se debe a que generalmente tengo muchas aplicaciones que consultan el servicio de autenticación desde varios lugares y la limitación no es práctica ni exigible. En ese caso, absolutamente debe tener buenas contraseñas, ya que son propensas a ataques de fuerza bruta.

    
respondido por el WoJ 29.06.2015 - 16:39
fuente

Lea otras preguntas en las etiquetas

¿Cuál es la diferencia entre DHE y ECDH? ¿Cuál es el propósito de cambiar el SSID predeterminado?