Cómo protegerse contra la fuerza bruta

El bloqueo de cuenta es una opción, donde la cuenta se bloquea permanentemente o por un período de tiempo después de x inicios de sesión fallidos. Los problemas aquí son los riesgos de denegación de servicio si un atacante intenta adivinar contraseñas y también la carga administrativa de restablecer las cuentas (suponiendo que no esté disponible un restablecimiento automático)

Otra opción es introducir CAPTCHA en el proceso de inicio de sesión. Esto tiene la intención de limitar los ataques automatizados y detener la denegación de servicio de los bloqueos de cuentas. Los problemas con él pueden ser los requisitos de accesibilidad y el craqueo automatizado de CAPTCHA. Por lo que he visto, algunos CAPTCHA son más fáciles de romper para el software que otros.

Una tercera opción es introducir un retraso progresivo en el proceso de inicio de sesión, por lo que para cada inicio de sesión incorrecto, el proceso se vuelve cada vez más lento. Esto tiene un efecto limitado en los usuarios reales, pero hace que la fuerza bruta automatizada sea mucho más difícil.

En términos de la segunda parte de tu pregunta sobre la identificación del "alguien" que realiza el ataque, depende de lo que estén haciendo. Si solo están atacando a un solo usuario, entonces el nombre de usuario es el identificador y las acciones están vinculadas a esa cuenta. Si son de fuerza bruta en una amplia gama de usuarios, la fuente de IP (tal vez combinada con el agente del navegador) es una opción. No es perfecto (p. Ej., Uso de botnets, suplantación de agentes), pero es probable que sea la única información que tendrías que seguir.

La respuesta a negar la fuerza bruta es negar un gran número de intentos, donde el espacio clave y la aceptación del riesgo definen un gran espacio.

Cada situación va a tener diferentes soluciones.

Espacio de carne

• Las puertas están reforzadas contra daños por fuerza bruta.
• El bloqueo a través de una puerta se ve mitigado por la posibilidad de alertar a la policía.
• Las claves solo tienen alrededor de 5 variables, pero se necesitan recursos para tener una de cada clave (es más fácil atacar la cerradura de otras maneras que no son fuerza bruta)

Computers

• La automatización de los ataques de fuerza bruta significa que necesitas un límite de velocidad de alguna manera. Con un límite de velocidad, puede conocer absolutamente la banda superior de intentos durante un período de tiempo determinado.
• Monitoreo: si puede limitar los intentos de fuerza bruta a una cierta frecuencia (quizás 500 / día), entonces el monitoreo y la alerta pueden avisar a una persona para que analice lo que está sucediendo. ¿Cuántos intentos se necesitarán para alcanzar un cierto nivel de riesgo inaceptable?
• Gran espacio de claves: tener requisitos de contraseña complejos puede aumentar considerablemente el número de intentos necesarios para una cierta probabilidad de encontrar la contraseña.
• Autentificación de dos factores: el hecho de que la contraseña no sea suficiente no es suficiente en este caso

Todas las soluciones también tienen concesiones como todo lo demás en la vida.

• Limitación de la tasa: pueden los usuarios legítimos de DoS, no son efectivos si el ataque es lo primero, un intento por cada cuenta antes de intentar una segunda vez
• Limitación de velocidad por IP: no es efectivo si se trata de un ataque distribuido
• Complejidad de la contraseña: suele ser una compensación en la usabilidad, lo que significa que los usuarios escribirán sus contraseñas, lo que reducirá la seguridad en mayor medida que la amenaza de fuerza bruta
• Dos factores: puede verse como caro, puede perder tokens

Como sugiero, te refieres al inicio de sesión / contraseña de fuerza bruta en la aplicación web.

Nadie hace fuerza bruta manualmente. Entonces, si hay dudas de que este es un humano que intenta autenticarse, muestre Captcha, por ejemplo, desde el intento de inicio de sesión fallido en 3-d. Además, puede poner un tiempo de espera entre intentos de inicio de sesión, pero esto no funcionará para ataques distribuidos de diferentes IP. A continuación, hay dos tipos de fuerza bruta: ciego, solo intento de inicio de sesión / contraseña aleatorios y ataque contra algún usuario. Para el último ataque es efectivo implementar una función como el bloqueo de la cuenta por algún tiempo y notificar al usuario por correo electrónico. Para los ciegos, la mitigación de la fuerza bruta puede ser más difícil de implementar, especialmente si el sitio es popular. En este caso, puede hacer un seguimiento de la información del usuario como IP / País / Navegador / etc, y descubrir una combinación de esto, puede hacer suposiciones sobre si este es un usuario válido. Como complemento a esto, puede jugar con cookies de larga duración: una vez que el usuario haya iniciado sesión correctamente, guarde la cookie y luego verifique si la tiene.

Sin la solución de tipo de aplicación web es posible implementar soluciones a nivel de servidor como mod_evasive de Apache. O incluso escriba su propio módulo de servidor web, específicamente para tales fines.

Claro, hay muchas otras formas de fortalecer la mitigación de ataques de fuerza bruta, pero a menudo resultan ser ruidosas, bastante inútiles y desagradables. Intenta seguir con KISS.

Lo importante es cómo identifica al 'alguien'?

No puede hacerlo por dirección IP: muchos usuarios pueden parecer que tienen la misma dirección de cliente (esto se hará aún más frecuente con el problema continuo de la falta de direcciones de IPV4).

Puede parecer que un usuario se conecta desde varias direcciones de clientes, por ejemplo, utilizando los proxies de carga equilibrada de AOL, o menos legítimamente, a través de tor.

Cualquier otra cosa son datos proporcionados por el cliente, por lo que potencialmente pueden modificar las cookies que establezca, la cadena de agente de usuario, etc.

El único enfoque práctico es aplicar la puntuación heurística a la solicitud para tratar de compararla con los intentos anteriores, pero aún será imposible diferenciar entre ataques sofisticados y usuarios legítimos.

Establezca un umbral de puntuación en el que considere que el cliente está tratando de forzar la fuerza bruta de su sitio, por ejemplo, -20.

Requerir una sesión válida actual a la que hace referencia una cookie de sesión (que no está configurada en la página que solicita un nombre de usuario / contraseña) es un comienzo: si la cookie no presenta los detalles de autenticación, entonces redirija a una página separada que deja caer la cookie e inicializa la sesión con una puntuación de -10, y una puntuación de (por ejemplo) -2 para la dirección IP del cliente. Podría usar un mecanismo de puntuación dinámico cuando comience a ver a varios usuarios válidos desde la misma dirección. Del mismo modo, puede mantener una puntuación dinámica por usuario-agente y por el nombre de usuario.

Cuando se presenta cookie + auth para un usuario inexistente, agregue una puntuación de -5 a la sesión, -1 a la dirección del cliente, -5 al nombre de usuario.

Cuando las cookies + autenticación se presentan con una contraseña no válida, agregue una puntuación de -3 a la sesión, -1 a la dirección del cliente, -4 al nombre de usuario.

Cuando cookie + auth + password valida agregue +4 de la puntuación para la dirección del cliente, +3 al nombre de usuario, +2 al agente de usuario.

NB: también debe establecer una caída para permitir que se recupere cualquier puntaje de la dirección del cliente / usuario-agente / nombre de usuario, digamos + 2 / hora

Debe pensar qué sucede cuando la puntuación supera el umbral. ¿Ha proporcionado un mecanismo para que alguien bloquee el acceso a su sitio?

Si ha bloqueado el acceso con un puntaje alto para un nombre de usuario en particular, envíe un correo electrónico con una URL de reinicio al usuario registrado para esa cuenta para que pueda restablecer el puntaje para su nombre de usuario y reducir el puntaje para su cuenta. usuario-agente / dirección.

Almacene los ips largos de inicios de sesión anteriores e intentos de inicio de sesión.

Después de N intentos fallidos, ponlos contra captcha.

Bloquee las direcciones rápidamente que no tienen inicios de sesión exitosos en su historial, pero sí varios intentos.

Bloquee las direcciones rápidas que tienen direcciones de origen simultáneas o intentos de velocidad / staminarapid inhumanos.

Además, ninguna de estas respuestas tiene en cuenta el método de forzamiento brutal en el que un atacante usa una contraseña y la prueba contra todas las cuentas, una reversión del proceso habitual y una contra la que generalmente no está protegida.

El control sería, por supuesto, tener un proceso de monitoreo para múltiples intentos contra diferentes cuentas con la misma contraseña, pero nuevamente es muy difícil de bloquear, incluso si provienen de una sola dirección, ¿cómo bloquea esa IP? Los usuarios válidos también pueden utilizarlo, o ¿simplemente abandonas los inicios de sesión con esa contraseña, con el riesgo de bloquear a un usuario válido con esa contraseña?

Y, por supuesto, si un atacante ejecuta este tipo de cosas desde una red distribuida, o durante un largo período de tiempo, ¿cómo correlaciona los incidentes en un perfil de ataque?

Los mecanismos generales de la industria incluyen bloqueo

• en intentos directos (más de 3, generalmente menos de 20)
• retraso progresivo
• herramientas estadísticas para bloquear incidentes que parecen distribuidos en bruto forzando

Primero, tiene sentido comprender qué escenarios / ataques pretende manejar:

• El usuario válido escribe erróneamente la contraseña incorrecta
• El usuario válido realmente olvidó su contraseña y está dispuesto a intentar manualmente cualquier cosa que se le ocurra
• El atacante intenta adivinar manualmente la contraseña de otra persona
• El atacante está utilizando una herramienta automatizada para forzar la contraseña de un usuario específico
• El atacante está utilizando una herramienta automatizada para forzar la aplicación bruta de la contraseña de cualquier usuario posible (es decir, la búsqueda en primer lugar)
• El atacante quiere impedir que un usuario específico acceda al sitio
• El atacante quiere impedir que la mayoría de los usuarios accedan al sitio
• El atacante quiere impedir que los administradores accedan al sitio
• Attacker quiere crear una gran cantidad de trabajo manual o le cuesta mucho a su organización de alguna otra manera.

(¿Lo ves? No es tan simple ...) Y hay diferentes soluciones para cada parte de estos ...

• No reveles una lista de nombres de usuario. No lo haga más fácil ... Esto incluye no revelar si el nombre de usuario es válido o no, al rechazar el inicio de sesión.
• Requerir una política de contraseña segura: larga y compleja.
• Haga que el mecanismo de "contraseña olvidada" sea fácil y notable. (Por supuesto, asegúrate de que eso también sea seguro).
• Cada vez que falla una solicitud de inicio de sesión, inicie sesión en la base de datos. Asegúrese de escribir el nombre de usuario, la dirección IP, la hora, etc.
• Si se reciben numerosas solicitudes fallidas para un nombre de usuario específico, marque a ese usuario en la base de datos como bloqueado por un corto tiempo. También aliente al usuario a utilizar la función "Olvidé mi contraseña", si está en la misma sesión.
• ¿Cuántas solicitudes fallidas? Depende . En resumen, lo que tenga sentido para su sitio, el número exacto no es crítico.
• ¿Cuánto tiempo debe estar bloqueado el usuario? Intervalos cortos. Matemáticamente, realmente no importa, siempre y cuando tenga una política de contraseña segura. De manera realista, comience con un intervalo muy corto de unos pocos minutos, luego, si continúa, hágalo incrementalmente más largo. P.ej. después de 5 intentos malos, bloquear por 5 minutos; después de otros 3 malos intentos, cierra por 15; después de otros 2, bloqueo para 30; etc.
• No bloquee las cuentas de usuario de forma permanente. Esto lleva a la cuenta DoS. Y también puede costarle mucho tiempo y dinero a su personal de apoyo.
• A pesar de los puntos anteriores, si su sitio es muy sensible, por ejemplo. una aplicación bancaria, es posible que desee considerar el bloqueo permanente hasta nuevo aviso, por ejemplo, hacer que el cliente entre en su sucursal.
• Los bloqueos deben ser por nombre de usuario, en la base de datos. No por sessionId, y no en la sesión del servidor web.
• Si recibe muchas solicitudes fallidas con diferentes nombres de usuario, pero desde la misma dirección IP, implemente un bloqueo incremental como el anterior, pero con mayor gracia e intervalos más cortos.
• Proporcione una función de "olvidó el nombre de usuario", además de la contraseña olvidada.
• Las cuentas de administrador deben tener un período de gracia más corto, intervalos más largos y nunca bloquearlas permanentemente.
• En cualquier caso, al bloquear un usuario o IP, envíe una alerta a los administradores. Sin embargo, no para el bloqueo repetido, no desea inundar la bandeja de entrada del administrador. Pero si continúa, eleva el nivel de alerta unas cuantas veces.
• No utilice CAPTCHA: la dificultad añadida mínima es trivial, en relación con el valor de acceder a la contraseña del usuario. (Hay muchas maneras de evitarlo, CAPTCHA está fundamentalmente roto, independientemente de la implementación ).
• Por supuesto, como lo indicó @ rox0r, la autenticación de múltiples factores podría ser adecuada para usted.
• Otra alternativa es lo que se conoce como " autenticación adaptativa ": si el usuario falló en el inicio de sesión, solicite información adicional (que se haya registrado previamente). Dependiendo de factores de riesgo adicionales (por ejemplo, ubicación, patrones de tiempo diferentes a los habituales, etc.), escale la información requerida para la autenticación exitosa. Por ejemplo, el producto AdaptiveAuthentication de RSA hace esto.

Si se trata de un sitio web comercial, utilice el certificado más la autenticación de contraseña. Sin un certificado válido, nunca llegan al punto de intentar adivinar la contraseña. También puede usar algo como RSA SecurID en lugar del certificado.