Guardar temporalmente inicios de sesión fallidos de contraseña para usar contra el ataque de fuerza bruta

2

Mi pregunta es sobre ataques de fuerza bruta en línea, que intentan autenticarse en el sitio web.

1) En el primer caso, si las solicitudes provienen de la misma ip, creo que esto es relativamente fácil, ya que después de algunos intentos fallidos podemos bloquear la ip por algún tiempo o mostrar un captcha, o aumentar la demora entre los intentos de inicio de sesión etc.

2) segundo caso, consideremos que el atacante está usando proxy, realizando solicitudes desde diferentes direcciones IP, pero apuntando a una cuenta específica, no estamos seguros de cuál es la mejor práctica aquí, pero tal vez muestre captcha solo para esta cuenta si hubiera muchos intentos fallidos de diferentes ips, o tal vez considerando los ips incluidos en la lista blanca del usuario. También advirtiendo de alguna manera al propietario de la cuenta también, que fueron inicios de sesión fallidos enlace

3) De todos modos, creo que los 2 ataques anteriores son más o menos posibles de descubrir. Pero para el tercer caso, si el atacante está usando múltiples ips (digamos miles o más) dirigiéndose a diferentes cuentas, pero usando la misma contraseña, ya que existe una mayor posibilidad de que al menos un usuario tenga esa contraseña. En este caso, si el atacante realiza algunas solicitudes por IP durante un tiempo razonable, tal vez podría verificar miles de cuentas para esa contraseña elegida sin ser detectado / bloqueado.

Ahora, ¿cuáles son las ventajas y desventajas de temporalmente, digamos a nivel de horas o días, guardar (en la base de datos) los hashes de contraseña de los intentos fallidos de inicio de sesión (con una sola aplicación - sal del lado), y si La contraseña que se solicitó mucho durante las últimas x horas / días requiere un captcha o algún otro tipo de defensa, incluso antes de verificar la contraseña.

Además, consideremos que las políticas de contraseña se aplican durante el registro, por ejemplo, contraseñas de 6 u 8 caracteres de longitud, lo que no permite el uso de contraseñas conocidas. Además, para el hashing de contraseñas habitual, estoy usando sal única por usuario (y usando blowfish o sha512), pero desea usar sal única para contraseñas fallidas y sha 256 o 384 para ser más rápido.

gracias

    
pregunta dav 31.08.2014 - 19:01
fuente

2 respuestas

1

La respuesta dependerá completamente de cómo defina su modelo de amenaza y de lo que permita su apetito de riesgo.

Ya que fue tan lejos como para identificar los posibles ataques con bastante detalle, asumo que usted cree que estos son creíbles y las posibles amenazas a las que se enfrenta. Si este no es el caso, no debería haber ninguna razón para tratar de protegerse contra ellos.

Pros

  • Como lo señala correctamente, almacenar temporalmente los hashes de fallidos intentos de contraseña potencialmente podrían darle los datos necesarios para Detectar más efectivamente un ataque como se describe en el escenario 3. Si esto El proceso puede requerir un indicador de captcha o un segundo factor de autenticación sin duda obstaculizará los intentos de la el atacante es suficiente para que el ataque sea poco práctico.
  • Podrías aprender mucho sobre la naturaleza de estos ataques a partir de los datos recopilados, como el tipo de contraseñas que intentan los atacantes y la forma en que los completan (ataques de fuerza bruta contra diccionario). Sin embargo, esto es más una ganancia académica que directamente relacionada con la seguridad de su sistema, aunque podría identificar tendencias a largo plazo que podrían resultar en mejores técnicas de identificación en el futuro.

Cons

  • La principal consideración que tendrá que hacer aquí es si vale la pena compensar la mayor seguridad en comparación con los recursos adicionales y el procesamiento requerido. Esto se debe al hecho de que las comparaciones que pretende realizar pueden ser muy costosas desde el punto de vista informático y podrían requerir una cantidad significativa de recursos adicionales (dependiendo del tamaño del sistema y la cantidad de intentos de inicio de sesión que espera recibir).
  • Sospecho que la comparación que intentas hacer para identificar estos ataques descritos en el escenario 3 no es tan simple como parece al principio. En primer lugar, como se indicó anteriormente, es posible que necesite algunos recursos más para almacenar y comparar los hashes de las contraseñas. En su descripción del escenario 3, usted asume que la solicitud proveniente de varias direcciones IP intentará la misma contraseña en todas las cuentas posibles a la vez. Esto significará que no podrá procesar cada solicitud de inicio de sesión por sí mismo, sino que tendrá que evaluar los intentos de inicio de sesión como un lote para poder ver que hay varios intentos de inicio de sesión en varios cuentas con la misma contraseña exacta. Recuerde que un usuario legítimo podría estar intentando iniciar sesión coincidiendo con el ataque y que deberá consultarse a todo el lote de intentos de inicio de sesión si se sospecha de la reproducción de aves. Esto podría llevar a una experiencia degradada desde la perspectiva del usuario si esto sucede con frecuencia. También será difícil determinar cuánto tiempo será necesario almacenar un hash específico después de que se haya marcado como un artefacto de un presunto ataque específico. No puede mantener el hash allí por tiempo indefinido, ya que podría ser el hash de la contraseña de un usuario legítimo que luego será consultado continuamente y esto podría llevarlo a usted, en esencia, a "DDoS'ing" su propio sistema. Si decide implementar un sistema como este, solo el rastro y el error a lo largo del tiempo podrán indicar cómo debe configurarse para que funcione de manera efectiva sin ser una carga demasiado grande.

Si su objetivo es proteger a sus usuarios y sus datos en su sistema en lugar de identificar específicamente estos ataques, le sugeriría que esté implementando un mecanismo de autenticación de múltiples factores (posiblemente incluso requiriéndolo). Educar a sus usuarios sobre las amenazas a las que se enfrenta y los beneficios de usar la autenticación de múltiples factores para protegerlos podría ser un enfoque mucho mejor para asegurar el sistema con mucha menos fricción y esfuerzo por su parte.

    
respondido por el ilikebeets 31.08.2014 - 22:04
fuente
0

No veo el punto de preocuparme por tu escenario # 3; esa táctica será tan exitosa como el escenario # 4:

  1. Una red de bots que se dirige a muchas cuentas que intentan una de las muchas contraseñas comunes en cada intento.

Imagina que tienes un millón de usuarios, el 10% de los cuales usa aleatoriamente una de las 1000 contraseñas más comunes ( 123456 , password , letmein , ...). Si una botnet intenta atacar a todos los millones de cuentas con la primera contraseña en la lista y luego intenta la segunda contraseña en la lista, abajo de la línea, cada intento de inicio de sesión tendrá una probabilidad de 1 en 10000 de trabajar. Si la red de bots elige aleatoriamente una contraseña para cada cuenta que ataca, tendrá la misma tasa de éxito. La única complicación es originalmente si la red de bots quería evitar el trabajo repetido, tenía que revisar la lista de cuentas registradas en algún tipo de orden (o hacer un seguimiento de las cuentas que ya se habían probado). Ahora solo tiene que ir a través de la lista de pares (inicio de sesión, contraseña) en algún tipo de orden (o realizar un seguimiento de los intentados) para evitar intentos inútiles.

Por supuesto, hay cosas que puede hacer para prevenir el escenario 3 & 4.

  1. No permita que los usuarios usen contraseñas comunes . Obtenga una gran base de datos de contraseñas filtradas y cada vez que un usuario configure o cambie una contraseña, asegúrese de que no esté en esta lista común. Tener reglas de complejidad de contraseñas también ayuda (p. Ej., Un capital, un número, un símbolo) que impiden muchas contraseñas comunes ( 123456 , password o letmein ): otorgadas, sus reglas deben ser flexibles para permitir frases largas como < a href="http://xkcd.com/936/"> correct horse battery staple .

  2. Lleve un registro de las direcciones IP asociadas con las cuentas . Si la cuenta johndoe nunca ha iniciado sesión correctamente desde 1.2.3.4 antes, requiera CAPTCHAs o autenticación de 2 factores (reciba un código por SMS / llamada telefónica / correo electrónico) antes de que puedan iniciar sesión desde esa IP.

respondido por el dr jimbob 11.03.2015 - 15:42
fuente

Lea otras preguntas en las etiquetas