L'un des problèmes qui se pose devant les ressources WEB ayant des comptes personnels est une attaque par force brute. Oui, une simple énumération de toutes les options de mot de passe pour un compte particulier. Bêtement? Peut-être, mais une telle attaque peut fortement charger la ressource. De plus, s'il n'y a aucun contrôle sur la complexité du mot de passe de l'utilisateur lors de l'inscription, il peut également réussir.
Le plus souvent, le problème est résolu relativement simplement. Si l'utilisateur a mal saisi le mot de passe plusieurs fois, son compte est bloqué pendant un certain temps. Une autre solution consiste à afficher le captcha. Immédiatement ou après plusieurs tentatives infructueuses. Eh bien, n'oublions pas l'autorisation 2F, qui est presque invulnérable. Il semblerait - profit! Mais tout n'est pas si rose ...
Regardons quelques-uns des problèmes décrits solutions:
Blocage temporaire - le compte utilisateur est temporairement bloqué et il ne peut pas accéder au système. Le véritable utilisateur pendant l'attaque éprouve du chagrin et des tourments. Il ne peut pas entrer dans le système. Et très probablement, il charge votre soutien. Et la chose la plus intéressante est que c'est peut-être le but de l'attaquant.
Captcha est une solution relativement bonne et efficace. La vérité est gênante pour l'utilisateur, vous obligeant à entrer quelque chose en plus. Assez "désagréable" à intégrer dans le design. Oh oui ... toujours cette chose, selon l'implémentation, peut être sujette à une attaque DoS.
Autorisation 2F - Tout est super. C'est vrai ... le plus souvent, c'est une chose facultative. Activez-le pour contrer l'attaque ne fonctionnera pas. Elle est là ou elle n'est pas. Et sur certaines ressources, entrez l'autorisation 2F, disons, tirez sur les moineaux du char.
J'essaie de créer des services pratiques et fiables. Par conséquent, j'ai décidé de me fatiguer un peu le cerveau. Et c'est ce qui s'est passé.
Si vous utilisez la messagerie, par exemple mail.ru, et que vous avez installé l'autorisation 2F, vous avez peut-être remarqué que l'autorisation 2F n'est demandée que pour un nouveau «périphérique» lors de la première connexion. De plus, l'appareil est considéré comme fiable. Et il vous suffit de saisir votre identifiant et votre mot de passe.
Chose pratique. Convivialité, pour ainsi dire. Ceci est implémenté par deux jetons. Le premier identifiant est «device» (défini comme devid), et le second est un identifiant de session (défini comme session). Devid, contrairement à la session, ne perd pas sa pertinence même après qu'un utilisateur a terminé une session. Il est transmis lors de la prochaine tentative de connexion, et si le nom d'utilisateur / mot de passe est correct, ainsi que devid trust, 2F n'est plus demandé. Mais, si la prochaine tentative de connexion a échoué, le jeton devid devient immédiatement mort. Et maintenant, vous devez suivre le chemin complet de l'autorisation.
Ce paradigme a été pris comme base. C'est-à-dire entrez le jeton devid, qui sera émis en permanence, avec toute réponse de la ressource WEB, bien sûr, si elle ne figurait pas dans la demande.
Pour le cas d'autorisation 2F, l'algorithme ci-dessus a été effectivement implémenté. Et immédiatement tout le monde est devenu heureux. T.ch. il n'est pas logique de l'examiner en détail. Mais les "cloches et sifflets", il vaut mieux considérer le schéma, avec des explications:
Même si l'autorisation 2F n'est pas installée, mais que la connexion a réussi, le jeton devid est marqué comme approuvé. Il semblerait que cela ait peu de sens de le faire sans l'autorisation 2F. Mais, tout est un peu plus délicat. Si nous savons que le devid est fiable, c'est-à-dire il avait une connexion réussie, nous supposons au moins que c'est à partir de cet appareil que le véritable utilisateur est entré. Il s'agit d'informations très importantes que l'algorithme décrit utilise dans son travail en mode de réflexion d'attaque.
Une stratégie a été adoptée: toute autorisation ne peut se produire que s'il existe un jeton de devid valide. Un écart valide diffère d'un écart de confiance en ce qu'il n'est pas encore approuvé, c'est-à-dire il n'y a pas eu de connexion réussie, mais le système est prêt à traiter les demandes d'autorisation avec. Le nombre de tentatives est limité à N fois par jeton valide. Si une erreur d'autorisation se produit plus de N fois de suite, le jeton est marqué comme «compromis». Il est transféré dans un journal séparé avec des statistiques sur la sélection. Les demandes avec sa participation continuent d'être traitées, mais ... il n'est plus possible de se connecter avec lui. Tout ce qui se passe, c'est l'accumulation de statistiques d'activité.
Les attaques les plus stupides se battent donc. Par exemple, si un attaquant, ignorant devid, tente de se connecter au système, ou s'il ne pouvait pas comprendre la logique de devid (comment sait-il combien de tentatives de connexion sont données avec le même devid?), Ses demandes sont terminées.
Son propre front sait qu'après N tentatives de connexion infructueuses d'un seul appareil, il est déjà «pourri». Vous devez maintenant obtenir un nouveau jeton, avant la prochaine tentative de connexion.
Il semblerait, quel genre de stupidité? Le front pour accomplir la tentative d'entrer ... mais, comme je l'ai dit plus haut, tout est plus délicat. Si un utilisateur travaille sur un front standard, la probabilité qu'il essaie vraiment d'attaquer le système est négligeable. Associé à un système de contrôle de la complexité des mots de passe lors de l'enregistrement des utilisateurs, cela est complètement futile. Très probablement, le véritable utilisateur essaie vraiment de se souvenir de son mot de passe.
Alors, quel est le truc? Dans le fait que sur le dos, nous générons le devid très valide avec un certain délai. Par exemple, pas plus de 1000 pièces par minute. Si soudainement cette limite est dépassée, le mode d'attaque est coupé. Et ici, vous pouvez soit aller radicalement et arrêter l'émission de devid pendant un certain temps, ce qui refroidira l'ardeur de l'attaquant, ou réduire la génération de devid valide. Et vous pouvez activer le même captcha pour tous les devid valides mais non fiables.
Ainsi, un système flexible pour contrôler et gérer les attaques est obtenu. Des mesures fiables sont générées par lesquelles la surveillance peut être déclenchée en déclenchant une alarme. Les statistiques accumulées peuvent être converties en règles de blocage, etc.
Un système convivial est dû au fait que les utilisateurs qui s'y étaient précédemment connectés, c'est-à-dire ont fait confiance à devid sans même remarquer l'attaque. Ils seront ignorés par le système sans aucun problème.
Maintenant, profitez. Cet algorithme est très bien implanté sur des ressources à très forte charge. Il y a eu, entre autres, des tentatives de DoS sur l'algorithme lui-même, mais même ici, il s'est avéré digne.