Brute force attaque failsafe login dans asp.net

Question

Je viens de lire un article disant que les mots de passe avec 7 caractères ne sont plus sûrs. Cependant, si le serveur augmente le temps de réessayer une tentative de connexion après chaque tentative de connexion, les attaques par force brute sont inutiles. Comment créez-vous une telle logique dans asp.net? D'une certaine manière, je suppose que le code côté serveur doit se souvenir de l'adresse IP qui a essayé de se connecter et devrait augmenter le temps de réponse à chaque nouvelle tentative?

Answer 1

L'adresse IP n'est pas vraiment une méthode sécurisée d'identification de l'utilisateur. Vous pouvez essayer de stocker la dernière fois qu'une tentative de connexion a été soumise dans un cookie, mais si le navigateur ne les accepte pas, l'utilisation sera limitée. Les variables de session nécessitent également des cookies, elles sont donc désactivées.

Certains sites (yahoo vient à l'esprit) commencent à montrer une forme Captcha après la troisième tentative. Vous devez répondre correctement au captcha en plus de vos informations de connexion. Une autre option serait de désactiver un compte après X tentatives infructueuses (qui peuvent être suivies dans votre base de données), mais personnellement, je n'aime pas cela car il me force à appeler quelqu'un pour réinitialiser mon mot de passe chaque fois que j'en oublie un.

Answer 2

De nombreuses attaques par force brute se produisent hors connexion. C'est la raison pour laquelle les lock-outs à tentative ratée ne se substituent pas à l'utilisation de mots de passe complexes, à l'utilisation d'un «salt» approprié et au renforcement des clés.

Answer 3

ASP.NET dispose d'un mécanisme intégré pour empêcher les attaques par force brute contre les mots de passe de connexion. Voir le maxInvalidPasswordAttempts Membership property. Les mots de passe IMHO à 7 caractères conviennent parfaitement à la plupart des applications Web (ma banque autorise 7 mots de passe) à condition que les meilleures pratiques de sécurité soient respectées, telles que le hachage sécurisé des mots de passe et le blocage des attaques brutes. Une fois que vous avez dépassé les mots de passe de 7 ou 8 caractères, vous dites vraiment que "mon application doit être super sécurisée", auquel cas vous devriez considérer les certificats SSL individuels des clients. Exiger plus de caractères dans un mot de passe a des rendements décroissants. Combien de vos utilisateurs peuvent se souvenir de mots de passe complexes à 8 ou 9 caractères? Ils finissent par les écrire. Personnellement, je me fais rejeter par n'importe quel site qui me demande de créer un mot de passe super complexe. L'adhésion ASP.NET fait le plus gros travail sur la sécurité pour vous, à condition qu'elle soit correctement configurée.

Cependant, il y a certaines choses ASP.NET Membership ne peut faire pour vous, tels que:

• Assurer HTTPS est utilisé
• Prévention CSRF et attaques similaires
• assurer que toutes les demandes Web sont acheminés vers ASP.NET pour empêcher le contenu statique étant servi par IIS et ASP.NET contourner l'authentification de
• Vérification que l'utilisateur est un être humain (CAPTCHA)

Pour en savoir plus sur les meilleures pratiques de sécurité, je regarderais OWASP

Answer 4

Il semble y avoir au moins trois attaques que vous voudrez peut-être à vous soucier:

• attaque ciblée à un utilisateur particulier. Vous voulez rendre la connexion plus difficile pour l'attackee, mais pas trop difficile.Un CAPTCHA est suffisant (mais ne rentrez pas le type d'utilisateur dans le mot de passe s'il n'était pas affiché sur la page de connexion).
• Attaque à grande échelle sur de nombreux utilisateurs. Le verrouillage d'utilisateurs individuels est un peu inutile, car l'attaquant peut simplement essayer (disons) 3 mots de passe, puis passer à un autre compte. Un CAPTCHA par IP peut être suffisant, mais vous pouvez également souhaiter limiter le taux par IP (ou X-Forwarded-For pour une liste de proxies en liste blanche). Cela dépend de la taille du botnet de votre attaquant. un botnet assez grand peut distribuer des attaques sur plusieurs robots/sites de sorte que chaque site obtienne un faible taux de chaque IP.
• Attaque hors ligne sur la base de données de mots de passe. Dans ce cas, vous avez besoin d'au moins environ 50 bits d'entropie même avec un bon hachage (NTLM utilise un seul appel de MD4 qui est pas un un bon hachage), que vous ne pouvez pas obtenir dans un mot de passe de 8 caractères relativement normal (8 log (94) est seulement 52,4).

Vous pouvez stocker try-per-IP dans une arborescence, où vous regroupez des parties denses de l'arborescence. Ensuite, il suffit de le placer dans un seau (construire un nouvel arbre toutes les 10 minutes, garder le vieil arbre pendant 10 minutes de plus). Cela a l'hypothèse possiblement erronée que les adresses IP voisines sont susceptibles de présenter un comportement similaire, mais se dégrade progressivement en regroupant simplement l'IPv4 en (disons)/24. Si vous vous sentez particulièrement généreux, vous pouvez stocker un cookie séparé lors de la connexion qui n'est pas effacé lors de la déconnexion et enregistrer une copie dans la base de données (une valeur aléatoire de 128 bits devrait suffire). Lors d'une tentative de connexion, soyez "plus agréable" au navigateur s'il présente le bon cookie (par exemple, autorisez 3 tentatives sur ce cookie sans compter le taux de défaillance par IP ou par utilisateur). Cela signifie que la dernière machine utilisée pour accéder au compte n'est pas présentée avec un CAPTCHA même lorsque le compte de l'utilisateur est brutforcé.

En général, il est plus utile de parler de l'entropie du mot de passe que la longueur du mot de passe et « types de caractères » — Je suis assez sûr que presque tout le monde est tout simplement la première lettre majuscule et des bâtons, un 1 sur la fin. Je n'ai pas encore vu de générateurs de mots de passe «humains» qui indiquent également l'entropie du mot de passe.