Prevención de fuerza bruta: ¿dónde y cuándo?

Las medidas del lado del cliente son solo una solución parcial (y en su mayoría cosmética), esto solo puede limitar los intentos no serios. Cualquier intento serio golpeará su servidor directamente porque se detectó una URL / API de inicio de sesión, o ejecutará a su cliente a través de un proxy interceptor para capturar los detalles necesarios para crear una ejecución de fuerza bruta.

Las defensas robustas generalmente requieren que asumas que el atacante sabe todo sobre el sistema, excepto la clave secreta ( Principio de Kerckhoff ) por lo que debes comenzar desde esa posición.

Las medidas de mitigación incluyen:

• dificulta / imposibilita que un atacante determine nombres de usuario válidos, contraseñas no válidas o cuentas bloqueadas (básicamente comentarios mínimos, es decir, no hay mensajes de "nombre de usuario no válido" o "contraseña demasiado larga", aunque emita un código de incidente único si esto es importante para el soporte al usuario). Como se señala en el comentario de My1 , el registro abierto puede ser un punto débil aquí.
• Para que sea difícil determinar algo que no sea el éxito o el fracaso, un inicio de sesión fallido debería tomar el mismo tiempo que uno exitoso; esto generalmente significa hacer que ambos sean artificialmente largos (200 ms es un punto de partida)
• haga que la API de inicio de sesión sea de varios pasos utilizando un token basado en nonce o algún tiempo o sesión para complicar los ataques automatizados y evitar ataques distribuidos; o agregue alguna prueba de trabajo del lado del cliente (el hashing de la contraseña del lado del cliente es una opción, pero necesita consideración cuidadosa )
• asegúrese de que el espacio para contraseñas sea lo suficientemente grande, fomente (¡y respalde!) el uso de un administrador de contraseñas
• use el bloqueo de la cuenta y el bloqueo de IP de origen con un aumento exponencial de los tiempos de bloqueo (por ejemplo, el doble del tiempo de bloqueo en cada falla, esto debería evitar molestar a un usuario que tiene una contraseña incorrecta un par de veces). Como se señaló en los comentarios, esta es una oportunidad para DOS, así que considere las compensaciones cuidadosamente
• implemente el control de velocidad adaptable y la detección de actividad maliciosa (esto generalmente es más difícil que cualquiera de las otras soluciones, ya que requiere un estado y una lógica adicionales en el lado del servidor)
• considere la posibilidad de agregar un modo de operación "bajo ataque" que se pueda habilitar según sea necesario, lo ideal sería que esto tenga un impacto mínimo en los usuarios

De CAPEC-112 Brute Force :

  

El factor clave en este ataque es la capacidad de los atacantes para explorar el posible espacio secreto rápidamente.   Si bien el defensor no puede controlar los recursos disponibles para un atacante, puede controlar el tamaño del espacio secreto.   El defensor debe confiar en asegurarse de que el tiempo y los recursos necesarios para hacerlo excedan el valor de la información.

Vea también CAPEC-49 Forzado de la Bruta de Contraseña

La forma habitual de prevenir un ataque de fuerza bruta es agregar un poco de retraso en el servidor.

Como se ha señalado en un comentario del usuario immibis , un atacante no necesita usar su aplicación para realizar una DoS o DDoS. Todo lo que necesita el atacante es el punto final, luego pueden inundarlo. Y pueden encontrar el punto final mediante la ingeniería inversa del archivo .apk, o simplemente monitoreando el tráfico saliente.

Así que la defensa debe estar en el lado del servidor. Al agregar un poco de retraso después de cada intento fallido de inicio de sesión (por ejemplo, 1 segundo), resulta poco práctico para un atacante probar millones de posibles combinaciones de nombre de usuario / contraseña.

Si desea proteger su servidor de los ataques DDoS en general, necesita un conjunto de servidores sólido o usar un servicio como CloudFlare.

Un aspecto importante es si hay algún tipo de material clave almacenado en el dispositivo que se puede usar para autenticar el dispositivo o si un usuario puede simplemente tomar un dispositivo nuevo, descargar la aplicación e iniciar sesión.

Si hay tal material clave en el dispositivo, es posible que el servidor aplique límites de velocidad por dispositivo. Otras formas de aplicar los límites de tasa del lado del servidor (como los límites de tasa por IP o por nombre de usuario) son posibles vectores de ataque DoS. Esto es cierto independientemente de si el límite de velocidad se implementa haciendo que el servidor realice cálculos pesados de la CPU como parte de la validación de la contraseña o mediante bloqueos temporales.

Cuando tiene el control tanto del código del cliente como del servidor, puede diseñar un protocolo en el que la parte pesada de la validación de la CPU se realice en el lado del cliente, pero el servidor sigue haciendo un hash con sal para asegurarse de que todavía tiene los beneficios del servidor. validación lateral. Obviamente, si implementa tal cosa desde cero, existe un riesgo de vulnerabilidades introducidas por fallas en el diseño o la implementación.

La ventaja de hacer el lado del cliente de parte intensiva de CPU es que elimina principalmente el vector de ataque DoS. Una desventaja de hacer el lado de cliente de parte intensiva de CPU es que el cliente puede estar limitado en recursos de CPU.

La combinación de los enfoques anteriores es posible. En el primer inicio de sesión, puede hacer que el cliente realice el hashing durante varios segundos, por ejemplo, enviando un salt al cliente y que haga muchas rondas de hashing; finalmente, el servidor realiza la última ronda del hashing con un salt diferente. Si se acepta la contraseña, el dispositivo envía un token que permitirá al cliente autenticarse en la misma cuenta con un hash secundario mucho más barato en el futuro. El servidor puede imponer un límite sobre la cantidad de intentos de inicio de sesión fallidos con el token que se permiten antes de que el token caduque y el cliente vuelva al hash más lento.

Una vez más, debo advertir que hay muchas formas de introducir fallas de seguridad en un diseño como este, por lo que hay que evitar el riesgo de ataques de fuerza bruta.

Es posible que se combinen las características de los dispositivos y la prueba de trabajo:

Si todos los dispositivos tenían que conectarse utilizando una clave autofirmada (~ 4096bit) como la identidad del dispositivo, y eso se usó para limitar la velocidad:

O bien

• cada dispositivo pasa demasiado tiempo generando nuevas claves; retrasando así los intentos de contraseña
• muchos inicios de sesión ocurren con la misma clave de cliente; Se garantiza que son dispositivos únicos maliciosos, por lo que se pueden bloquear sin riesgo de servicio DOS.
• se produce algún tipo de intercambio de claves de botnet contra los inicios de sesión; limitado por el poder de los dispositivos disponibles para generar nuevas claves: ¿qué tan valioso es un servicio para su objetivo en comparación con cuánto tiempo puede hacer que los usuarios esperen la primera generación de claves de inicio de sesión / certificado?

O simplemente conviértalo en un problema ajeno: use un sistema público de autenticación de 2 factores.