Les protections que vous décrivez sont bonnes que vous devriez considérer, mais il peut encore 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 fr masse pour vous (il existe des entreprises qui vendent ce service).
• Le verrouillage de compte est une bonne idée, mais si vous le faites sur la base de l'adresse IP, une personne ayant accès à un botnet pourrait réessayer de se connecter sur un seul compte à partir de différents IP: s jusqu'à ce qu'ils entrent.
• Hors ligne La force brute est toujours un problème si votre base de données subit une fuite. Si l'attaquant a accès au hachage du 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 s'attaque à une seule cible.

Il existe un autre scénario dans lequel l'attaquant a choisi quelques mots de passe courants "password, password123, 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.

  Utilisateur: JimPW: password, password123, letmein, secretUser: BobPW: password, password123, letmein, secretUser: AlicePW: password, password123, letmein, secret  

Ceci est plus courant dans les scénarios où les attaquants cherchent à collecter des informations d'identification pour les revendre sur le darknet, ou à effectuer des mouvements 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 global de connexions invalides, plutôt que simplement par compte ou par IP.

C'est une menace dans un sens différent. Si vous verrouillez les comptes pendant 15 minutes après 5 tentatives infructueuses, alors vous avez effectivement intégré un mécanisme DoS.

Supposons que je ne veux pas vraiment m'introduire par effraction, mais je suis d'accord pour simplement provoquer ravages, pas de problème. Faites quelques milliers de connexions par seconde avec des noms d'utilisateurs aléatoires. Hé, je ne prendrai même pas la peine de faire le CAPTCHA, peu importe. Tout ce que je veux, c'est échouer et verrouiller .

Une meilleure stratégie qu'un laps de temps fixe après un nombre fixe d'échecs pourrait être quadratique ( ou exponentielle). Certains routeurs AVM le font. Premier échec de connexion, vous avez 15 secondes de verrouillage, le prochain échec vous en avez 30, etc. Ceci est beaucoup moins compliqué pour les utilisateurs légitimes, et beaucoup plus de problèmes pour les attaquants.
Afin de rendre DoS plus difficile, vous auriez besoin d'un type de recette impliquant l'adresse IP ainsi que le nom du compte, en 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. La croissance exponentielle résout mieux le problème du "nombre infini de tentatives", cependant.

En fait, trouver une paire nom d'utilisateur-mot de passe en ligne par la force brute est, eh bien, en supposant que les gens ne sont pas ' t stupide, 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. Alors, oui, il y a là aussi une menace. En particulier parce qu'il peut être difficile de cibler un utilisateur sur un serveur, sur un système de contrôle purement basé 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 mille serveurs en parallèle. Et, cela ne vous coûte vraiment rien de faire fonctionner ce script pendant des semaines (des mois, des années ...), réessayer toutes les 15-20 minutes.

Donc, alors que pour le compte individuel , vos chances en tant qu'attaquant sont très faibles, car les nombres s'additionnent à, eh bien, pratiquement l'infini , vous êtes obligé de frapper quelqu'un, quelque part. , finalement, c'est inévitable. Dans la mesure où sinon il est trivial d'essayer un millier d'utilisateurs en parallèle, il doit être clair que vous devez également prendre en compte les adresses IP dans votre calcul. Même ainsi, cela ne protège pas à 100% contre un botnet avec quelques milliers de robots, mais cela rend l'attaque un peu moins efficace, nécessitant plus de travail et de gestion. Plus de travail est bon.

Vous ne pouvez pas gagner la course une fois que vous êtes une cible sérieuse, mais plus vous faites le travail d'un attaquant, plus il est probable que l'attaquant choisisse quelqu'un d'autre (qui est une cible plus facile) à commencez par.
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 vous ne pouvez finalement rien 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 solution 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 la 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 de manière triviale par un humain mais pas par un ordinateur.
• Tentatives de force brute contre un seul utilisateur ne sont pas les seules attaques potentielles auxquelles vous devez faire face. Il n'est pas rare que les attaques essaient le même ensemble de mots de passe sur une liste de noms de comptes connus. Il n'est pas non plus inhabituel pour certains services susceptibles d'avoir une poignée de noms d'utilisateur bien connus (SSH par exemple) de voir des attaques de mappage d'utilisateurs.
• À moins que vous n'appliquiez une forme de vérification de la qualité des mots de passe, c'est raisonnablement probable qu'une tentative de force brute n'aura pas besoin de suffisamment d'essais pour 5 essais toutes les 15 minutes pour la ralentir suffisamment.

Idées pour améliorer ce que vous avez proposé:

• Comme mentionné ci-dessus, appliquez la qualité du mot de passe. Dans une situation idéale, permettez à des choses comme la méthode de génération de mot de passe XKCD de fonctionner (voir XKCD # 936 pour plus d'informations à ce sujet), et mieux encore, assurez-vous que tout caractère Unicode valide est accepté.
• Renvoie exactement un code d'échec pour un échec d'authentification dû à des informations d'identification invalides, au lieu d'en avoir différents pour les noms d'utilisateur et les mots de passe invalides. Ceci est vraiment important, car il protège contre les attaques de mappage utilisateur.
• 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 ce que fournissent 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 mis en place. Quoi qu'il en soit, si vous procédez de cette façon, autorisez plusieurs méthodes MFA (idéalement un mélange de différents types). Évitez tout ce qui nécessite l'envoi des codes de connexion par e-mail (ce n'est absolument pas sécurisé) ou SMS (c'est mieux que l'e-mail, mais peut prendre un très long délai avant que le code ne soit reçu). Tous les utilisateurs qui activent l'authentification multifacteur sont alors fonctionnellement protégés contre la plupart des attaques par force brute.
• N'utilisez pas simplement un système 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, définissez le temps égal à 15 * 2 ^ n minutes avec une limite de 2 heures, où n est le nombre de verrouillages précédents au cours des 24 dernières heures (première tentative est un lock-out de 15 minutes, le deuxième est 30, le troisième est de 60, le quatrième et les suivants 120).

Il existe des attaques par force brute à faible vitesse, conçues spécifiquement pour pénétrer dans des comptes avec des délais d'expiration ou des verrouillages.

Si l'attaquant peut déterminer vos seuils (ce qu'il peut par des 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 donnée, c'est pourquoi ces types d'attaques durent souvent des mois ou des années et sont peu susceptibles de compromettre les comptes avec des mots de passe raisonnablement longs.

Donc, en combinaison avec une politique de mot de passe sensée (c'est un sujet différent, ici je dirai simplement que complexité! = sécurité et longueur> complexité) et une mise en œuvre 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 à limite de débit, le verrouillage de compte, etc. sont bons pour arrêter toute attaque par force brute économiquement réalisable contre un écran de connexion, mais ce n'est pas nécessairement ainsi que l'attaque est effectuée.

Très souvent, les comptes sont compromis parce que l'attaque par force brute n'est pas effectuée contre l'écran de connexion lui-même (ce qui est limitatif) mais contre une copie des données. Si un attaquant peut accéder aux données via un serveur compromis ou un 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 après goutte après goutte. Je considérerais le captcha comme un 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 y a plusieurs comptes, je peux toujours automatiser le processus pour continuer à essayer.

Je ne pourrai pas forcer brutalement tout l'espace de clés possible avec vos contraintes, mais je pourrai forcer le haut 1000 mots de passe par compte en un peu plus de 2 jours.

Étant donné qu'une liste des 1000 meilleurs mots de passe couvrirait très probablement un pourcentage raisonnable de vos utilisateurs, vous devriez pouvoir accéder à votre système très bientôt.

Vous aussi vous défendre?

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, qu'en est-il de la même adresse IP qui essaie plusieurs 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 élément tout à fait 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, en fonction de ce que vous utilisez et du nombre d'authentification 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 de la qualité de votre cible. Si vous êtes une cible souhaitable, alors oui, c'est une menace.

Alors qu'un délai d'expiration avec une limite de débit et un verrouillage prendra en charge la force brute, car ils n'obtiendraient que X essais en Y minutes , c'est un énorme problème car il permet à des attaquants extérieurs de verrouiller vos utilisateurs presque sans effort.

Dans ce cas, vous avez le choix entre les menaces. Vous décidez qu'en échange de la protection des comptes individuels, un attaquant peut verrouiller les utilisateurs. C'est une attaque différente de celle qui consiste à 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 les deux opérations, vos comptes seront raisonnablement en sécurité et vos utilisateurs ne seront pas verrouillés.

La vulnérabilité ici est considérablement réduite car l'attaquant devra voler et déchiffrer votre base de données de mots de passe et vos secrets 2FA pour y accéder, mais au moment où ils sont suffisamment en profondeur pour le faire, ils ne le font pas. en fait, ils ont plus besoin des comptes utilisateurs.

Tout dépend vraiment de ce que vous protégez. Si c'est un blog Wordpress et que les utilisateurs ne peuvent pas commenter votre dernier message, ce n'est pas un gros problème. Si votre site contient des documents financiers, médicaux ou de sécurité, c'est une énorme affaire.