Uno de los problemas que surge frente a los recursos WEB que tienen cuentas personales es un ataque de fuerza bruta. Sí, una simple enumeración de todas las opciones de contraseña para una cuenta en particular. Estúpidamente? Quizás, pero tal ataque puede cargar mucho el recurso. Además, si no hay control sobre la complejidad de la contraseña del usuario durante el registro, también puede ser exitosa.
Muy a menudo, el problema se resuelve de manera relativamente simple. Si el usuario ha ingresado la contraseña incorrectamente varias veces, su cuenta está bloqueada por algún tiempo. Una solución alternativa es mostrar captcha. Inmediatamente, o después de varios intentos fallidos. Bueno, no nos olvidemos de la autorización 2F, que es casi invulnerable. Parecería - beneficio! Pero, no todo es tan color de rosa ...
Veamos algunos de los problemas descritos soluciones:
Bloqueo temporal : la cuenta de usuario se bloquea temporalmente y no puede ingresar al sistema. El usuario real durante el ataque experimenta angustia y tormento. No puede entrar al sistema. Y lo más probable es que cargue su apoyo. Y lo más interesante es que quizás este sea el objetivo del atacante.
Captcha es una solución relativamente buena y efectiva. La verdad es inconveniente para el usuario, ya que requiere que ingrese algo allí adicionalmente. Suficiente "desagradable" para incrustar en el diseño. Ah sí ... aún esto, dependiendo de la implementación, puede estar sujeto a un ataque DoS.
Autorización 2F : todo es excelente. Es cierto ... la mayoría de las veces esto es algo opcional. Enciéndelo para contrarrestar el ataque no funcionará. Ella está allí o no está. Y en algunos recursos, ingrese la autorización 2F, digamos, dispare gorriones desde el tanque.
Intento crear servicios convenientes y confiables. Por lo tanto, decidí tensar un poco mi cerebro. Y eso es lo que pasó.
Si usa el correo, por ejemplo mail.ru, y tiene instalada la autorización 2F, es posible que haya notado que la autorización 2F solo se solicita para un nuevo "dispositivo" en el primer inicio de sesión. Además, el dispositivo se considera confiable. Y solo necesita ingresar su nombre de usuario y contraseña.
Cosa conveniente. Fácil de usar, por así decirlo. Esto se implementa mediante dos tokens. El primer identificador es "dispositivo" (definido como devid), y el segundo es un identificador de sesión (definido como sesión). Devid, a diferencia de la sesión, no pierde su relevancia incluso después de que un usuario finaliza una sesión. Se transmite en el siguiente intento de inicio de sesión, y si el nombre de usuario / contraseña es correcto, así como devid confiable, 2F ya no se solicita. Pero, si el siguiente intento de inicio de sesión no tuvo éxito, el token devid inmediatamente se desactiva. Y ahora debe seguir el camino completo de la autorización.
Este paradigma fue tomado como base. Es decir ingrese el token devid, que se emitirá constantemente, con cualquier respuesta del recurso WEB, por supuesto, si no estaba en la solicitud.
Para el caso de autorización 2F, el algoritmo anterior se implementó realmente. E inmediatamente todos se volvieron felices. T.ch. no tiene sentido examinarlo en detalle. Pero las "campanas y silbatos", es mejor considerar el diagrama, con explicaciones:
Incluso si la autorización 2F no está instalada, pero el inicio de sesión fue exitoso, entonces el token devid se marca como confiable. Parece que tiene poco sentido hacer esto sin la autorización de 2F. Pero, todo es un poco más complicado. Si sabemos que devid es de confianza, es decir tuvo un inicio de sesión exitoso, al menos suponemos que fue desde este dispositivo que entró el usuario real. Esta es información muy importante que el algoritmo descrito utiliza en su trabajo en modo de reflexión de ataque.
Se adoptó una estrategia: cualquier autorización puede ocurrir solo si hay un token devid válido. Un devid válido difiere de uno confiable en que aún no es confiable, es decir, no hubo inicios de sesión exitosos, pero el sistema está listo para procesar solicitudes de autorización con él. El número de intentos está limitado a N veces por token válido. Si se produce un error de autorización más de N veces seguidas, el token se marca como "comprometido". Se transfiere a un diario separado con estadísticas sobre la selección. Las solicitudes con su participación continúan procesándose, pero ... ya no es posible iniciar sesión con él. Todo lo que sucede es la acumulación de estadísticas de actividad.
Entonces los ataques más estúpidos contraatacan. Por ejemplo, si un atacante, ignorando devid, intenta iniciar sesión en el sistema, o si no puede entender la lógica de devid (¿cómo sabe cuántos intentos de inicio de sesión con el mismo devid?), Sus solicitudes se terminan.
El propio frente sabe que después de N intentos fallidos de inicio de sesión de un devid, ya está "podrido". Ahora necesita obtener un nuevo token, antes del próximo intento de inicio de sesión.
Parecería, ¿qué tipo de estupidez? El frente para cumplir el intento de entrar ... pero, como dije anteriormente, todo es más complicado. Si un usuario trabaja a través de un frente estándar, la probabilidad de que realmente esté intentando atacar el sistema es insignificante. Junto con un sistema de control de complejidad de contraseña durante el registro del usuario, esto es completamente inútil. Lo más probable es que el usuario real realmente esté tratando de recordar su contraseña.
Entonces, ¿cuál es el truco? En el hecho de que en la parte posterior generamos el devid muy válido con un cierto límite de tiempo. Por ejemplo, no más de 1000 piezas por minuto. Si de repente se supera este límite, se corta el modo de ataque. Y aquí puedes ir radicalmente y detener la emisión devid por un tiempo, lo que enfriará el ardor del atacante o reducirá la generación de devid válidos. Y puede habilitar el mismo captcha para todos los devid válidos, pero no confiables.
De este modo, se obtiene un sistema flexible para controlar y gestionar ataques. Se generan métricas confiables mediante las cuales se puede activar el monitoreo que genera una alarma. Las estadísticas acumuladas se pueden convertir en reglas de bloqueo, etc.
Un sistema amigable es porque aquellos usuarios que previamente iniciaron sesión en él, es decir he confiado en devid sin siquiera notar el ataque. El sistema los omitirá sin ningún problema.
Ahora lucro. Este algoritmo está muy bien establecido en recursos con una carga muy alta. Hubo, entre otros, intentos de DoS en el algoritmo en sí, pero incluso aquí resultó ser valioso.