¿Debe bloquearse la cuenta de usuario después de X cantidad de inicios de sesión fallidos?

Question

¿Debe bloquearse la cuenta de usuario después de X cantidad de inicios de sesión fallidos?

#1 de Matthew (3 votos)

3

Casi he terminado de desarrollar mi sistema de inicio de sesión y hay una cosa más de la que no estoy seguro. Tantos debates que encontré en Internet sobre el conteo de inicios de sesión no válidos y el bloqueo de cuentas de usuarios. Mi sistema almacena los nombres de usuario y las contraseñas (que están salted [para cada usuario salt diferente] y hash) en la base de datos. Si el usuario ingresa un nombre de usuario o contraseña no válidos, hago un seguimiento de su nombre de usuario, contraseña, tiempo de inicio de sesión, ID de sesión, IP y navegador. Aquí está el ejemplo:

LoginID   LoginTime                 LoginUN    LoginPW    LoginSessionID    LoginIP     LoginBrowser    
   1    2018-03-15 13:40:25.000     jpapis     test       E72E.cfusion      10.18.1.37  Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0
  98    2018-03-15 13:48:45.000     mhart      mypass55   E72E.cfusion      10.12.1.87  Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0
  32    2018-03-15 14:29:14.000     skatre     1167mmB!   378E.cfusion    10.36.1.17    Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0

¿Me pregunto si debo bloquear la cuenta después de X intentos? Si es así, ¿cuál sería la mejor práctica para hacer eso? Aquí hay un enfoque que encontré:

SELECT COUNT(LoginID) AS countID, DATEDIFF(mi,LoginTime,GETDATE ( )) AS TimeElapsed
FROM FailedLogins
WHERE (LoginUN = '#username#' OR LoginSessionID = '#SESSION.sessionid#' OR LoginIP = '#REMOTE_ADDR#')
    AND DATEDIFF(mi,LoginTime,GETDATE ( )) <= 60
GROUP BY LoginID, LoginTime
HAVING COUNT(LoginID) >= 5;

La consulta anterior buscará un nombre de usuario, ID de sesión o dirección IP. Si alguno de estos se encuentra en la tabla FailedLogin dentro de los 60 minutos y es mayor que 5, bloquearía la cuenta. El único problema aquí es que no estoy seguro de lo que esto evitaría, el ataque de fuerza bruta puede enviar demasiados intentos en 60 minutos, así que no estoy seguro de cuál sería el beneficio de verificar los inicios de sesión fallidos de esta manera. ¿Hay una mejor manera de manejar los inicios de sesión fallidos ahora días? ¿Debo incluso bloquear la cuenta? Si alguien puede proporcionar algunos pensamientos y ejemplos, por favor hágamelo saber. También quiero compartir algunos detalles sobre el sistema. No tenemos ninguna transacción de dinero en el sistema o vinculada a cuentas de usuario. Tenemos información confidencial en el sistema y es por eso que me gustaría implementar una función de seguridad para evitar que los piratas informáticos intenten romper la contraseña con algunas de las técnicas de piratería informática. Gracias.

passwords authentication brute-force account-security account-lockout

pregunta espresso_coffee 16.03.2018 - 14:29

fuente

1 respuesta

Lea otras preguntas en las etiquetas passwords authentication brute-force account-security account-lockout

VeraCrypt montó la seguridad del contenedor ¿Agregar una ventana acoplable no es una buena idea?

score 3 · Answer 1

Los bloqueos de cuenta en aplicaciones remotas (por ejemplo, donde el atacante no puede restablecer el número de intentos sin más trabajo) son principalmente para evitar ataques fáciles de fuerza bruta contra cuentas. Si tiene usuarios que seleccionan contraseñas muy débiles o comunes, y su sistema no intenta impedir su uso, es completamente posible que un atacante pueda obtener acceso a algunas cuentas, incluso con el bloqueo de cuenta implementado. Sin embargo, eso no significa que no valga la pena implementarlo, para los usuarios que seleccionan contraseñas ligeramente mejores, frena de forma masiva a un atacante y puede alertar a usted o a sus usuarios sobre posibles ataques.

Esto es diferente a elegir un método de almacenamiento de contraseña, que generalmente intenta defenderse contra los atacantes que han obtenido su base de datos de usuarios. Obviamente, en ese caso, no puede evitar que alguien haga tantos intentos para adivinar la contraseña como desee; simplemente puede codificar varias contraseñas con el salt de su base de datos y compararlas hasta que encuentren una contraseña que proporcione la misma información. hash.

Sin embargo, el método específico que está utilizando para registrar los intentos fallidos es un problema. Estás registrando el nombre de usuario y la contraseña incorrecta. En la mayoría de los casos, la probabilidad de que un usuario legítimo escriba incorrectamente su contraseña es mayor que la de un atacante que intenta iniciar sesión en el sistema. En ese caso, la tabla de registro que mantiene se vuelve valiosa para los atacantes, ya que contiene nombres de usuario con cadenas que probablemente estén cerca de contraseñas válidas para las cuentas. Si los usuarios tienen contraseñas solo para su sitio, esto podría disminuir enormemente el esfuerzo requerido para forzar las contraseñas de fuerza bruta si se accedió a su base de datos, y si los usuarios tienen cuentas en otros sistemas con las mismas contraseñas, incluso si los otros sistemas usan esquemas de bloqueo de cuenta, acaba de darles a los atacantes una mejor oportunidad de adivinar la contraseña correcta dentro del límite de intentos.

No es necesario almacenar la contraseña. Solo te importa el número de intentos contra cada cuenta. Ese podría ser un valor entero vinculado al loginid, y sería suficiente para su proceso de bloqueo. Puede almacenar por separado la IP de origen y monitorear patrones de tráfico inusuales, aunque corre el riesgo de bloquear a usuarios legítimos que se conectan a su sitio a través de conexiones NAT-ed. Los proveedores móviles a menudo agrupan grandes cantidades de usuarios para que parezcan provenir de un Dirección IP única, por ejemplo.

Un patrón común para el bloqueo de cuenta es monitorear la cantidad de intentos fallidos contra una cuenta, y luego aplicar bloques de tiempo incrementales contra esa cuenta. Por ejemplo, después de 3 intentos fallidos, podría bloquear otros intentos durante 5 minutos. Si se producen otros 3 intentos fallidos, bloquee la cuenta durante 10 minutos, y así sucesivamente, esto se puede restablecer una vez que se produce un inicio de sesión legítimo. También puede ser útil mostrar el número de intentos fallidos a los usuarios al iniciar sesión: si detectan algo extraño, pueden alertarlo de un problema.

Una cosa sutil que se debe tener en cuenta al implementar esquemas de bloqueo de cuenta es que pueden actuar como un nombre de usuario oracle, si se implementan de manera deficiente. En este caso, es posible detectar un comportamiento distinto entre cuentas válidas y cuentas inexistentes, informando a un atacante que un nombre de usuario determinado es válido. Para evitar esto, puede supervisar todos los nombres de usuario proporcionados y mostrar el mismo comportamiento para los que no existen o para los válidos, o simplemente no mostrar cuando una cuenta está bloqueada. Si elige esto, puede causar confusión a los usuarios, quienes no podrán iniciar sesión si están sujetos a un ataque sin su conocimiento.