Il existe plusieurs réponses utiles sur la prévention de la brute forçant un mot de passe d'un service Web en appliquant une étranglement. Je n'ai pas trouvé de bons chiffres cependant et j'ai peu d'expertise dans ce domaine, la question est donc la suivante:
Combien de tentatives prend-il généralement à la force brute-force un mot de passe moyen de 6 caractères ou plus (sans aucune connaissance supplémentaire qui peut aider, mais en tenant compte de ce que les mots de passe sont probablement sujets aux attaques de dictionnaire) et en fonction de ce que sont des limites significatives à appliquer à l'algorithme d'étranglement sans perturber l'expérience utilisateur?
Ceci est mon schéma actuel:
dormir appliqué à chaque récupération de la page de connexion de # des tentatives / 5 , donc après 5 demandes avec moins d'une minute entre les demandes 'LL prend> 1 seconde pour aller chercher le formulaire, après 10 demandes> 2 secondes, etc.
-
En outre, je n'autorise que 100 tentatives de connexion en panne par compte d'utilisateur avec 2 heures entre tentatives, après que le compte soit bloqué pendant 2 heures.
- Pour éviter de fréquenter des comptes, les IP peuvent être blanchisseuses (sans limites appliquées) ou sur la liste noire (toute tentative de connexion ignorée complètement).
basé sur les réponses jusqu'à présent, je l'ai modifié pour travailler comme ceci:
- La récupération du formulaire de connexion est progressivement ralentie sur une base IP. Chaque nouvelle demande est dormi pour
# des demandes / 2 secondes. Le compteur est réinitialisé après 10 minutes d'aucune activité de connexion.
- Je garde une pile FIFO de tentatives de connexion pour chaque IP. Si une adresse IP ne parvient pas à se connecter 30 fois dans les 2 heures, elle est suspendue. Je garde également une liste de nombre de suspensions par IP et que le temps de suspension est calculé comme
2 ^ (# de suspensions + 1) heures . Cela devrait conduire à une liste noire de facto rapide d'IPS perfectionnant continuellement.
- En outre, si un compte n'a pas réussi à se connecter 20 fois dans un jour, il est suspendu pendant 2 heures. Je ne suis pas trop sûr de cette mesure, car cela signifie que cela signifie que peut être assez facilement. À court de bottnet distribué massif, les IP offensant devraient devenir de facto sur la liste noire plus rapidement qu'un compte peut être définitivement DOS'D. C'est également une mesure assez efficace pour protéger un compte.
Je pense que ces limites ne doivent pas nuire aux utilisateurs normaux, même ceux qui oublient régulièrement leur mot de passe et tentent de se connecter plusieurs fois. Les limites IP devraient également fonctionner correctement avec les utilisateurs lourds, compte tenu de la taille moyenne du service. Quelqu'un peut-il prouver que cela sera efficace ou inefficace avec des mathématiques solides? :)
3 Réponses :
de la question que cela semble être le plus rapide qu'ils puissent essayer d'essayer 50 mots de passe par minute. Basé sur cela et en utilisant des mots de passe aléatoires à 6 chiffres:
Bien sûr, les attaques de dictionnaires seraient beaucoup plus rapides, mais je n'ai pas les chiffres pour cela.
Edit: j'ai essayé de relier les résultats de Google Calculatoriat Sauvegarde de cette opération, mais EDIT2:
Attaques de dictionnaire (de http://www.outpost9.com/files/wordlists.html ):
Le dernier est effrayant, mais 12 jours est encore longtemps. Si vous êtes vraiment inquiet, vous pouvez suivre chaque mot de passe incorrect jusqu'à ce que l'utilisateur obtienne un mot de passe correct, puis si la liste devient sur 100 tentatives différentes, interdire simplement l'adresse IP et envoyer un courrier électronique à l'utilisateur. ^ semble gâcher des liens ici.
Prenant le Dormez TEMPS et une limite supplémentaire sur tentatives par compte, je pense que le plus rapide serait beaucoup plus lent. Donc, il semble assez bon?
C'est ce que je m'étais dis. Pourquoi se soucier d'être plus précis lorsque vous ignorez toutes vos caractéristiques de sécurité, à l'exception de l'un des résultats moyens de 6 ans? Combien de temps une attaque d'un dictionnaire prend peut-être cependant intéressant.
Un autre facteur serait si vous exécutez un type de complexité autre que 6 caractères ou plus, cela affecterait l'efficacité de toute attaque de force brute. Nous supposons également qu'ils ont déjà un identifiant de connexion valide?
Mes numéros supposent qu'ils ont un identifiant de connexion valide. Je n'ai pas calculé plus de 6 chiffres dans les tests de mot de passe aléatoires, car les chiffres augmentent de manière exponentielle (même un mot de passe de 6 chiffres aléatoires à 6 chiffres est presque incassable, un 7 chiffre est 26X plus difficile).
Merci pour la mise à jour. Ces chiffres semblent un peu plus effrayant. Je pense que simplement sur la liste noire des IP avec x nombre d'essais défaillants serait délicate pour les utilisateurs fortement nés. C'est là que les 100 essais sont censés lancer, il faudrait au moins 16 heures pour même passer à la liste des mots de passe les plus courants. Peut-être que la liste noire automatiquement une adresse IP s'il trottise de cette limite deux fois dans un certain (plus long) délais est une bonne idée?
Je pense que le moyen le plus simple de le faire est de demander un email valide, puis il suffit de connecter n'importe quelle adresse IP avec plus de x tentatives (et d'envoyer un email de réactivation).
Désolé, mais cela semble être une idée étrange. Si un attaquant essayait de pirater un certain compte, l'attaquant deviendrait sur la liste noire et le titulaire du compte recevrait un email lui demandant de débloquer l'attaquant ...?
Non, l'attaquant obtiendrait la liste noire et le titulaire du compte obtiendrait un email indiquant qu'il aurait pu être tentative d'attaque sur leur compte (assurez-vous de mentionner que l'attaquant n'a pas compris), puis a quelque chose comme "si le système accidentellement bloqué votre adresse IP, vous pouvez le débloquer ici ».
Le problème que je vois avec c'est qu'il y a trop de participation des utilisateurs. La plupart des utilisateurs ne sauront pas ce qu'est une adresse IP, beaucoup moins leur propre adresse IP. Je pense que cela éviterait simplement les utilisateurs avec peu d'avantages réels. Le système devrait fonctionner sans que l'utilisateur soit conscient de celui-ci. Je préférerais qu'ils me contactent personnellement (qui conviennent de toute façon au reste du service) s'ils se trouvent incapables de se connecter.
Probablement vrai :( Le CAPTCHA ralentirait beaucoup les gens de toute façon.
Vous avez quelques bonnes contrôles là-bas, mais vous devriez vraiment le resserrer davantage. Un utilisateur régulier ne devrait pas manquer de se connecter plus de cinq fois. S'il le fait, montrez-lui un CAPTCHA.
N'oubliez pas qu'en cas de problème ne devriez vous verrouiller le compte. C'est ce qu'on appelle une vulnérabilité de verrouillage de compte. Cela permet à un utilisateur arbitraire de déconnecter d'autres utilisateurs du service (DOS, déni de service).
J'ai approché ce problème de connexion de connexion à plusieurs reprises et celui que j'aime, c'est que vous créez un champ de tentatives infructueuses et la dernière tentative ayant échoué dans votre base de données. Chaque fois que quelqu'un (quiconque) ne parvient pas à se connecter à Compte X, vous augmentez la valeur des tentatives infructueuses de X et mettez à jour la dernière date de tentative d'échec. Si le nombre de tentatives ayant échoué dépasse Y (par exemple, cinq), indiquez une captcha pour l'utilisateur spécifique. Donc, vous n'aurez pas une énorme base de données d'IPS interdite pour accélérer le formulaire de connexion, mais vous n'avez que deux autres champs par utilisateur. Il a également peu de sens à interdire / à l'étranglement basé sur IPS, à cause de botnets et de procurations (à la fois juridiques et illégales). Lorsque IPv6 sort à la mode, vous serez plus condamné que je présume. Il est beaucoup plus logique d'étrangler sur des comptes ciblés. Ainsi, lorsque votre compte X est ciblé par un botnet, le formulaire de connexion sera réservé à un CAPTCHA. L'inconvénient évident ici est que si votre CAPTCHA échoue ... VOTRE LOGIN DE COMMUNAIRE.
Donc, dans l'essence, cela va comme ça:
C'est essentiellement un bouclier qui s'allume lorsqu'il y a une attaque ciblée massive contre des comptes particuliers. La bonne chose à propos de ce type d'approche est que cela n'aura pas d'importance si je possède une ferme de PC à travers le monde - je ne peux pas brute la force d'un seul compte, car il est basé sur le compte.
Les deux mauvaises choses à ce sujet sont que si le CAPTCHA échoue, vous n'avez plus rien. Vous pouvez bien sûr améliorer cette situation en plaçant également d'autres protections. Le deuxième problème est que si j'avais un bot-net, je pourrais utiliser un ordinateur pour un compte, puis il est probable qu'avec un million de réseau informatique, je craque au moins un compte, mais cette approche ne fonctionne que dans des attaques non ciblées.
J'espère que cela vous a donné des pensées.
C'est bien conseiller en effet, la suspension d'un compte est une mesure plutôt désordonnée, bien que efficace. :) Je me demande si s'il y a quelque chose de mieux qu'un captcha.
Nous avons eu recours à captcha aussi dans un scénario similaire: peu de premières tentatives sont gratuites, puis montrez à CAPTCHA. ReCAPTCHA semble fonctionner assez bien (ils fournissent également de l'audio, bien que en anglais).
J'aime généralement la réponse de @ Tower, mais préférez une variante qui n'utilise pas CAPTCHA, principalement parce que je la déteste comme une expérience utilisateur.
En plus de ses champs de suivi de panne, ajoutez également un champ de verrouillage avec un horodatage. J'accepte que fermer un utilisateur pour toujours (ou jusqu'à la réinitialisation manuelle) fait une mauvaise expérience, mais verrouillent un compte pendant une heure (tout en douceur douloureux) est un moyen de dissuasion efficace .
Le changement serait alors que lorsque le décompte d'échec est incrémenté au-delà du seuil, le champ de verrouillage est défini sur Verrouillage manuellement des comptes d'une perspective administrative devient alors juste une question de réglage du champ de verrouillage sur une valeur future lointaine comme maintenant + 1 heure . Chaque fois que l'authentifie est en cours d'exécution, il regarde ce champ et si verrouillage> maintenant , puis il échoue.
9223372036854775807L (max 64 bits signé long).