La force brute est-elle une menace probable même si vous activez les connexions CAPTCHA et les limites de débit?
Supposons que CAPTCHA est activé avec le contrôle de verrouillage du compte (après cinq tentatives infructueuses continues, le compte sera verrouillé pendant 15 minutes) sur un système.
La force brute est-elle toujours une menace probable?
Les protections que vous décrivez sont de bonnes que vous devriez considérer, mais il peut toujours y avoir des faiblesses:
- De nombreux CAPTCHAS peuvent être résolus par des robots, ou vous pouvez facilement payer des gens pour les résoudre en masse pour vous (il existe des entreprises qui vendent ce service).
- Le verrouillage du compte est une bonne idée, mais si vous le faites sur la base de l'IP, quelqu'un ayant accès à un botnet pourrait réessayer de se connecter sur un seul compte à partir d'IP différentes jusqu'à ce qu'il entre.
- Hors ligne la force brute est toujours un problème en cas de fuite de votre base de données. Si l'attaquant a accès au hachage de mot de passe, il peut essayer tout ce qu'il veut sur son propre système. C'est pourquoi vous devez utiliser un bon hachage.
Peut être.
cela dépend de la façon dont vous définissez la "force brute".
Un verrouillage après X tentatives incorrectes est idéal pour protéger un compte où un attaquant poursuit une seule cible.
Il y a un autre scénario où l'attaquant a choisi quelques mots de passe courants "mot de passe, mot de passe123, etc." Et plutôt que d'attaquer un seul utilisateur, ils essaient leurs 4 mots de passe communs sur chaque compte qu'ils connaissent dans votre système.
User: Jim
PW: password, password123, letmein, secret
User: Bob
PW: password, password123, letmein, secret
User: Alice
PW: password, password123, letmein, secret
Ceci est plus courant dans les scénarios où les attaquants cherchent à récolter des informations d'identification pour les revendre sur le darknet, ou à effectuer des déplacements latéraux vers d'autres services où les mots de passe peuvent avoir été réutilisés.
Je vous suggère d'ajouter quelque chose en place pour compter le taux de connexions non valides globales, plutôt que simplement sur un compte ou un niveau IP.
C'est une menace dans un sens différent. Si vous verrouillez les comptes pendant 15 minutes après 5 tentatives infructueuses, vous avez effectivement intégré un mécanisme DoS.
Supposons que je ne veuille pas vraiment entrer par effraction, mais je suis content de ne faire que des ravages, pas de problème. Effectuez simplement quelques milliers de connexions par seconde avec des noms d'utilisateur aléatoires. Hé, je ne prendrai même pas la peine de faire le CAPTCHA, qui s'en soucie. Tout ce que je veux c'est échouer et verrouiller.
Une meilleure stratégie qu'une durée fixe après un nombre fixe de défaillances peut être une croissance quadratique (ou exponentielle). Certains routeurs AVM font cela. Échec de la première connexion, vous avez 15 secondes de verrouillage, échec suivant, vous en avez 30, etc. Ceci est beaucoup moins compliqué pour les utilisateurs légitimes et beaucoup plus de problèmes pour les attaquants.
Pour rendre le DoS plus difficile, vous auriez besoin d'une sorte de recette impliquant l'adresse IP ainsi que le nom du compte, plafonnant le délai maximum par paire compte-IP à une valeur tolérable. Sinon, un utilisateur légitime pourrait toujours être DoSed facilement et indéfiniment. Cependant, la croissance exponentielle résout mieux le problème du "nombre infini de tentatives".
En fait, trouver une paire nom d'utilisateur-mot de passe en ligne par force brute est, bien, en supposant que les gens ne sont pas stupides, pratiquement sans espoir. Malheureusement, les gens sont stupides, vous ne pouvez donc pas supposer qu'ils n'auront pas l'un des dix mots de passe les plus stupides, et vous devez supposer que c'est faisable. Donc, oui, il y a aussi un peu de menace. En particulier parce qu'il peut être difficile de cibler n utilisateur sur un serveur, sur un système de contrôle basé uniquement sur le nom d'utilisateur, vous pouvez cibler un millier d'utilisateurs sur ce même serveur en parallèle sans problème (chaque score uniquement un seul échec!) et vous pouvez le faire sur un millier de serveurs en parallèle. Et, cela ne vous coûte vraiment rien de garder ce script en cours d'exécution pendant des semaines (mois, années ...), en réessayant toutes les 15-20 minutes.
Donc, alors que pour le compte individuel vos chances en tant qu'attaquant sont très petites, alors que les nombres s'additionnent, eh bien, pratiquement l'infini vous êtes obligé de frapper quelqu'un, quelque part, finalement, c'est inévitable. Puisqu'il est trivial d'essayer un millier d'utilisateurs en parallèle, il devrait être clair que vous aussi devez prendre en compte les adresses IP dans votre calcul. Malgré cela, il ne donne pas une protection à 100% contre un botnet avec quelques milliers de bots, mais il rend certainement l'attaque un peu moins efficace, nécessitant plus de travail et de gestion. Plus de travail, c'est bien.
Vous ne pouvez pas gagner la course une fois que vous êtes une cible sérieuse, mais plus vous faites travailler un attaquant, plus il est probable que l'attaquant choisisse quelqu'un d'autre (qui est une cible plus facile) pour commencer.
C'est à peu près la même chose que de verrouiller votre porte d'entrée au lieu de la laisser grande ouverte. Un cambrioleur peut facilement casser votre fenêtre et il n'y a finalement rien que vous puissiez faire pour empêcher quelqu'un d'entrer. Mais étant donné le choix d'une porte ouverte chez le voisin et d'avoir à casser votre fenêtre, il choisira probablement la voie la plus facile. Moins de dépenses, même profit.
Oui, c'est toujours une menace, car:
- Les CAPTCHA approchent très rapidement du théâtre de sécurité. Il existe de nombreux services qui peuvent les casser (pour un prix), et il devient de plus en plus difficile de trouver des problèmes qui peuvent être résolus trivialement par un humain mais pas par un ordinateur.
- Les tentatives de force brutale contre un seul utilisateur ne sont pas les seules attaques potentielles auxquelles vous devez faire face. Il n'est pas rare que des attaques essaient le même ensemble de mots de passe contre une liste de noms de comptes connus. Il n'est pas non plus trop inhabituel pour certains services qui sont susceptibles d'avoir une poignée de noms d'utilisateur bien connus (SSH par exemple) de voir les attaques de mappage des utilisateurs.
- À moins que vous n'imposiez une forme de vérification de la qualité des mots de passe, il est raisonnablement probable qu'une tentative de force brute n'aura pas besoin de suffisamment d'essais pendant 5 essais toutes les 15 minutes pour la ralentir suffisamment.
Des idées pour améliorer ce que vous proposez:
- Comme mentionné ci-dessus, appliquez la qualité du mot de passe. Dans une situation idéale, autorisez le fonctionnement de la méthode de génération de mot de passe XKCD (voir XKCD # 936 pour plus d'informations), et mieux encore, assurez-vous que tout caractère Unicode valide est accepté.
- Renvoyez exactement un code d'échec pour un échec d'authentification en raison d'informations d'identification non valides, au lieu d'en avoir d'autres pour les noms d'utilisateur et les mots de passe invalides. C'est vraiment important, car il protège contre les attaques de mappage des utilisateurs.
- Fournir un support MFA. Ce n'est en fait pas difficile à faire correctement si vous prenez le temps de le configurer. Les méthodes TOTP MFA (telles que celles fournies par l'application Google Authenticator et le système MFA de Steam) sont généralement assez faciles à mettre en œuvre et sont raisonnablement sécurisées. U2F est également assez sécurisé mais nécessite plus de travail pour être configuré. Quoi qu'il en soit, si vous optez pour cette méthode, autorisez plusieurs méthodes MFA (idéalement un mélange de différents types). Évitez tout ce qui nécessite d'envoyer les codes de connexion par e-mail (ce n'est absolument pas sécurisé) ou SMS (c'est mieux que par e-mail, mais cela peut avoir un très long délai avant que le code ne soit reçu). les utilisateurs qui activent MFA sont ensuite fonctionnellement protégés contre la plupart des attaques par force brute.
- N'utilisez pas seulement un dispositif de verrouillage statique. Utilisez plutôt une approche adaptative, où la durée pendant laquelle le compte reste verrouillé est basée sur le nombre de fois où il a été récemment verrouillé. Un système de mise à l'échelle exponentielle simple avec une limite supérieure sur le temps de verrouillage fonctionnera assez bien. Par exemple, rendez le temps égal
15 * 2^nminutes avec un plafond de 2 heures, oùnest le nombre de verrouillages précédents au cours des 24 dernières heures (la première tentative est un verrouillage de 15 minutes, la seconde est de 30, la troisième de 60, la quatrième et les suivantes de 120 ).
Il existe une chose telle que les attaques par force brute à faible vitesse, conçues spécifiquement pour pénétrer dans les comptes avec des délais d'expiration ou des verrouillages.
Si l'attaquant peut déterminer vos seuils (qu'il peut par essais), il peut écrire un bot pour rester juste en dessous de ce seuil.
Bien sûr, cela limite le nombre de combinaisons qu'il peut essayer dans une période de temps donnée, c'est pourquoi ces types d'attaques durent souvent des mois ou des années et ne risquent pas de compromettre les comptes avec des mots de passe raisonnablement longs.
Ainsi, en combinaison avec une politique de mot de passe saine (c'est un sujet différent, ici je vais juste dire que la complexité! = Sécurité et longueur> complexité) et une implémentation solide de votre système décrit, vous pouvez réduire considérablement la probabilité d'un compromis. Dans la plupart des cas, suffisamment pour que le risque restant soit bien dans votre limite d'acceptation du risque.
Les connexions de limite de taux, le verrouillage de compte, etc. sont bons pour arrêter toute attaque par force brute économiquement faisable contre un écran de connexion, mais ce n'est pas nécessairement la façon dont l'attaque est effectuée.
Très souvent, les comptes sont compromis car l'attaque par force brute ne se fait pas contre l'écran de connexion lui-même (ce qui limite) mais contre une copie des données. Si un attaquant peut accéder aux données via un serveur compromis ou tout autre moyen, l'attaque par force brute consiste en réalité à télécharger les comptes et les mots de passe, puis à casser le cryptage sur une machine beaucoup plus puissante.
La force brute n'a pas besoin d'utiliser beaucoup de "force". La force brute peut durer des jours et être une goutte minuscule, mais persistante, goutte après goutte. Je considérerais le captcha comme un non-problème pour tout attaquant déterminé.
Même avec vos contraintes, vous avez laissé entendre que ces limites ne s'appliquent qu'à un seul compte. Donc, si je sais qu'il existe plusieurs comptes, je peux toujours automatiser le processus pour continuer d'essayer.
Je ne pourrai pas forcer brutalement tout l'espace de clés possible avec vos contraintes, mais je pourrai forcer les 1000 premiers mots de passe par compte en très peu de temps sur 2 jours.
Étant donné qu'une liste des 1000 premiers mots de passe couvrirait très probablement un pourcentage raisonnable de vos utilisateurs, vous devriez pouvoir accéder à votre système très rapidement.
Pouvez-vous donc vous défendre contre cela?
Limiter l'essai par IP? -> Vecteur pour l'éviter: Botnets/VPN
Ajoutons donc "voyage impossible" à la liste? (L'utilisateur se connecte depuis l'Allemagne et les États-Unis en une minute)
Alors que diriez-vous que la même IP essaie différents utilisateurs?
Une chose à considérer est la valeur de la ressource que vous essayez de protéger et les mesures supplémentaires que vous souhaitez prendre pour la sécuriser. Un autre ajout assez sûr à la force de votre système est un deuxième facteur. Mais ceux-ci peuvent entraîner un coût supplémentaire pour vous, selon ce que vous utilisez et le nombre d'authentifications que vous devez effectuer. Par exemple, en tant que service autonome, Azure facturera 1,4 $ pour 10 authentifications. Ou vous pouvez utiliser une sorte de service gratuit ou un système "Grid" avec des données uniques par utilisateur.
La force brute est-elle toujours une menace probable?
"Probable" dépend du goût de votre cible. Si vous êtes une cible souhaitable, alors oui, c'est une menace.
Bien qu'un délai d'attente avec une limite de taux et un verrouillage se charge de la force brute, car ils n'obtiendraient que X essais en Y minutes, c'est un énorme problème car il permet aux attaquants extérieurs de verrouiller vos utilisateurs sans presque aucun effort.
Dans ce cas, vous avez le choix entre les menaces. Vous décidez qu'en échange de la protection de comptes individuels, un attaquant peut bloquer les utilisateurs. C'est une attaque différente de celle de voler/modifier des données, mais c'est toujours une attaque.
Une meilleure solution serait d'exiger des mots de passe forts et une authentification à deux facteurs et de ne pas avoir de verrouillage.
Si vous effectuez ces deux opérations, vos comptes seront raisonnablement sûrs et vos utilisateurs ne seront pas verrouillés.
La vulnérabilité ici est considérablement réduite car l'attaquant devra voler et casser votre base de données de mots de passe et les secrets 2FA pour y accéder, mais au moment où ils sont suffisamment en profondeur pour le faire, ils n'ont plus besoin des comptes d'utilisateur.
Tout dépend vraiment de ce que vous protégez. S'il s'agit d'un blog Wordpress et que les utilisateurs ne peuvent pas commenter votre dernier message, ce n'est pas grave. Si votre site contient des dossiers financiers, médicaux ou de sécurité, c'est une affaire énorme.