Récemment, lors de la conférence OWASP AppSec 2010 à Orange County, Bill Cheswick de AT&T a longuement parlé de cette question.

En bref, les recherches sont insuffisantes.

En long, voici quelques-unes de ses idées pour un verrouillage de compte moins pénible:

• Ne comptez pas les tentatives de mot de passe en double (ils pensaient probablement l'avoir mal saisi)
• Faites un indice sur le mot de passe mot de passe principal, et n'ont pas de (faible) secondaire
• Autoriser une partie de confiance à se porter garant de l'utilisateur, afin qu'il puisse changer son mot de passe.
• Verrouiller le compte de plus en plus incréments
• Rappelle à l'utilisateur les règles de mot de passe.

Tout site Web conforme aux Normes de sécurité des données PCI doit respecter les sections

• 8.5.13 (Limitez les tentatives d'accès répétées en verrouillant l'ID utilisateur après un maximum de six tentatives)
• 8.5.14 (Définissez la durée de verrouillage sur trente minutes ou jusqu'à ce que l'administrateur autorise l'utilisateur ID).

C'est malheureusement la raison pour laquelle de nombreux sites acceptant les cartes de crédit ont des politiques de verrouillage draconiennes, même si leurs concepteurs ne sont pas nécessairement d'accord avec ce qu'ils ont mis en œuvre.

Modifier: notez que ces exigences s'appliquent uniquement aux systèmes destinés aux "utilisateurs non consommateurs". Elles ne devraient donc pas affecter les sites clients acceptant les cartes.

D'après mon expérience, les mécanismes de verrouillage sont de moins en moins populaires (du moins pour les applications Web). Au lieu de verrouiller les comptes après une série de tentatives infructueuses, vous commencez à demander des informations supplémentaires pour une authentification réussie.

Je ne serais pas surpris si cela venait de la règle des "trois coups" du baseball plutôt que de quelque chose de technique.

Une justification (pour les mots de passe alphanumériques de toute façon) est

Typiquement, une tentative infructueuse est soit une erreur de frappe, soit un problème d'activation / désactivation des CAPS. Donc, vous essayez de vous connecter et d'être rejeté (1), essayez à nouveau parce que vous pensez que vous avez mal tapé (2) puis réalisez que la touche MAJUSCULES est activée, donc vous entrez à la troisième tentative.

Non Ce n'est pas vraiment valable pour le déverrouillage des téléphones mobiles d'un réseau quand il s'agit généralement d'un code numérique entré.

De meilleures suggestions sont un délai toujours croissant entre les tentatives de connexion successives infructueuses. Vous autorisez d'abord une nouvelle tentative instantanée, puis 1 seconde, 2, quatre, huit ... Vous attendez rapidement une minute entre les tentatives, ce qui est suffisant pour simuler toute attaque par force brute.

Je suis d'accord avec le PO. Si vous pensez à ce contre quoi le verrouillage vous protège, il n'y a aucune différence entre 3 ou 20 tentatives (ou 100, d'ailleurs) .Tout ce que vous obtenez avec ces verrouillages, à part punir les utilisateurs oublieux, est d'empêcher une attaque par force brute. . Vous pouvez également l'utiliser pour déclencher un avertissement indiquant qu'une attaque est en cours, mais ce n'est pas le but principal (si c'était le cas, cela signifie que vous faites délibérément vos utilisateurs juste pour faciliter votre propre travail de surveillance. Ce n'est pas une très bonne pratique).

Si quelqu'un a votre base de données de mots de passe, et peut la pirater hors ligne, il a des essais illimités. Votre limite de 20 suppositions n'est pas bonne là-bas.

Si quelqu'un tente une force brute en ligne, tout ce dont vous avez besoin est un mot de passe qui peut résister "assez longtemps": assez longtemps pour que votre IRT réponde , ou assez longtemps pour que votre attaquant abandonne.

La base de données de mots de passe Conficker est légèrement inférieure à 200 mots de passe, IIRC, et elle est remplie de certains des mots de passe les plus stupides de la planète. Supposons maintenant que votre mot de passe ne figure pas dans cette liste. Si vous autorisez 20 tentatives de mot de passe, par exemple toutes les 15 minutes, sans verrouillage, il faudra plus de deux heures à un attaquant pour parcourir cette liste.

En fait, même si vous réduisez votre liste de devinettes à mots de passe créés à partir d'informations pertinentes sur cet utilisateur, comme kidsname02, birthday99, etc., vous vous retrouverez toujours avec au moins quelques dizaines de mots de passe, prolongeant une attaque par dictionnaire à peut-être une heure ou plus. déclenchez vos alarmes, pas une poignée de mauvais mots de passe en quelques minutes.

Donc, si vous pouvez garder vos utilisateurs à l'écart des pièges les plus élémentaires de mot de passe, vous pouvez accepter de nombreuses tentatives de mot de passe erronées.

Personnellement, je trace la ligne à 15. Totalement arbitraire, et surtout pratique: je trouve que tout utilisateur réel a abandonné bien avant cela. Habituellement, s'il y a autant de tentatives, c'est un processus ou une session qui se bloque quelque part avec d'anciennes informations d'identification. Et si ce n'est pas le cas, nous pouvons parler de recherche d'attaques.

C'est une règle arbitraire idiote qui comporte un risque d'une étrange sorte d'attaque DDOS. Disons que Marv déteste le site Web X et le site Web X a un nombre Y de politique de verrouillage des tentatives. Marv pourrait soulever un véritable enfer en demandant à un script d'essayer automatiquement des noms aléatoires Y fois avec de faux mots de passe. Même si un mot de passe fonctionnait, Marv s'en moquerait probablement et l'ignorerait. Cela verrouillerait efficacement de nombreux utilisateurs du site Web X et causerait beaucoup de frustration aux utilisateurs, et que Dieu les aide s'ils sont une banque que vous devez appeler pour réinitialiser votre mot de passe. Je suis surpris que personne n'ait essayé cela.

Je crois que je suis en retard dans ce débat, mais j'espère avoir quelque chose d'utile à ajouter ici.

La politique de verrouillage de compte (avec le nombre de tentatives non valides consécutives généralement de l'ordre de quelques chiffres pour la plupart des organisations) n'a pas été conçu uniquement contre les attaques automatisées par force brute.

Il s'agit davantage d'une protection contre la devinette de mot de passe par des attaquants humains, en particulier par des individus qui connaissent déjà une partie du mot de passe. Les attaquants pourraient obtenir des fragments de mot de passe en

• surfer sur l'épaule
• en devinant les modèles employés par un individu pour choisir ses mots de passe. Après tout, combien de fois a-t-on utilisé des mots de passe avec des éléments dans une séquence, comme password # 01 , password # 02 etc.

L'inconvénient, bien sûr, est qu'avec une valeur seuil faible, il y a forcément un déni de service et un coût associé pour l'entreprise. Le Livre blanc sur les bonnes pratiques de verrouillage de compte publié par Microsoft fournit une valeur recommandée de 10. Il explique également comment estimer la probabilité d'une attaque réussie, en utilisant les paramètres de la politique de verrouillage de compte de Windows:

À titre d'exemple, supposons que l'administrateur réinitialise le mot de passe lorsque le compte est verrouillé avec la valeur de registre LockoutDuration de 0. Avec la valeur de registre LockoutDuration définie sur 0 et la valeur de registre LockoutThreshold sur 20, le l'utilisateur malveillant a 20 suppositions à utiliser contre ce mot de passe. Si la durée de verrouillage est de 30 minutes, l'utilisateur malveillant a 20 suppositions toutes les 30 minutes par rapport à ce mot de passe jusqu'à ce qu'il soit modifié. Il s'agit d'une différence très significative dans le nombre total de suppositions disponibles pour l'utilisateur malveillant.

En comparaison, si l'administrateur définit l'âge maximal du mot de passe à 42 jours, le premier utilisateur malveillant n'a que 20 suppositions contre n'importe quel mot de passe, alors que le deuxième utilisateur malveillant a 40320 suppositions (20 tentatives de verrouillage à jamais, multipliées par 48 verrouillages chaque jour, multiplié par 42 jours avant que l'utilisateur ne modifie le mot de passe). Avec les paramètres de mot de passe par défaut, il existe environ 10 ^ 12 mots de passe possibles. Cela signifie que l'utilisateur malveillant a environ .000004 pour cent (%) de chances de deviner le mot de passe. Avec un schéma de devinettes optimisé, ce pourcentage serait très probablement un pourcentage plus élevé.

Bien sûr, il n'est pas facile pour un profane de choisir un nombre approprié, et de telles décisions doivent être soigneusement prises pris en considération. Par conséquent, on peut supposer que certaines organisations n'ont pas fait l'effort de calculer les effets monétaires de leur politique de verrouillage de compte, et l'avantage associé d'assouplir leur politique tout en conservant l'avantage de sécurité qu'elle fournit.

Il y a deux aspects à cela; le premier, comme vous l'avez mentionné, est d'empêcher les attaques par force brute.

Pour cela, n'importe quel nombre d'essais devrait faire - 3, 5, 20, 2000 ... avec une politique de mot de passe appropriée (longueur + complexité + ...) donnant un espace clé suffisamment grand, tout type de limitation (X nombre d'essais par heure) garantira que le forçage brutal de l'espace entier prendrait plusieurs décennies. (Faire le calcul).

Même si - et cela devrait être une exigence - le verrouillage n'est que temporaire, et après une courte période, il se déverrouille automatiquement.

Ainsi, le nombre d'essais avant le verrouillage est arbitraire.

Cependant, il y a un autre problème, plus subtil et non mathématique en jeu ici:

Cela n'a tout simplement pas de sens pour un seul utilisateur de mettre à plusieurs reprises une erreur mot de passe 2000 fois de suite.

Autrement dit, si vous choisissez arbitrairement 2000 fois, vous savez longtemps avant cela que ce n'est PAS un utilisateur légitime. Ainsi, cela se résume vraiment à ce qui est sensé sur le plan commercial et à un compromis d'analyse des risques axé sur l'entreprise.

Je pense qu'historiquement, le compromis était plus orienté vers le risque - puisque les mots de passe étaient plus courts et moins complexes, la différence de 3 ou 10 était plus grande. De plus, les gens avaient moins de mots de passe, donc ils étaient plus faciles à retenir ... Et les utilisateurs étaient plus avertis techniquement en général.

De nos jours, trois n'ont vraiment aucun sens, compte tenu de l'impact commercial. Il s'agit en fait de savoir ce qui a du sens pour votre application, quels types d'utilisateurs, à quelle fréquence ils se connectent, etc. Je recommande généralement de déterminer combien de tentatives légitimes ont échoué, puis de le doubler.

( Comme @realworldcoder l'a mentionné, PCI a choisi arbitrairement six, et si vous êtes soumis au PCI, vous n'avez pas beaucoup de décision ici. Sinon, choisissez un nombre qui a du sens pour vous.)

En ce qui concerne les suggestions de `` verrouillage '' incrémenté dans le temps pour retarder les tentatives infructueuses successives et ainsi empêcher le forçage brutal, n'oubliez pas que cela ne fonctionne que sur les attaques d'utilisateurs ciblées.

Si l'attaquant ne se soucie que de à propos de l'accès au système, ils pourraient effectuer une première attaque de grande ampleur (cycle tous les noms d'utilisateur connus / devinés avant de passer au mot de passe suivant). Ajoutez que si cela a été fait correctement cela pourrait provenir d'un réseau distribué de machines, il est assez facile de voir que le système de délai ne fonctionne pas non plus.

Comme mentionné par d'autres, une surveillance correcte des tentatives infructueuses il est essentiel de découvrir les attaques tôt.

Oui, 3 tentatives est assez arbitraire et présente un risque de déni de service. Je souhaite vraiment que les gens arrêtent d'utiliser pour les systèmes publics ... S'il vous plaît!

Une autre solution: l'identification à 2 facteurs. Jetons RSA. Si seulement nous avions un moyen de posséder personnellement un seul jeton RSA avec un «numéro d'identification». Nous pourrions alors enregistrer ce 'numéro d'identification' avec n'importe quel système, ce qui nécessiterait alors la valeur actuelle du jeton avec le mot de passe pour se connecter.

Mais cela pose un tout autre tas de problèmes pour la mise en œuvre et confiance ...

Les entreprises publiques (qui vendent des actions en bourse) sont réglementées par la loi Sarbanes-Oxley et font l'objet d'un audit de conformité plusieurs fois par an. Les applications logicielles critiques doivent se conformer à certaines fonctionnalités de sécurité, notamment pour verrouiller les comptes après des tentatives de mot de passe infructueuses.

La majorité de ces applications, ce qu'elles font, c'est s'intégrer dans l'Active Directory de l'entreprise qui a déjà les fonctionnalités activées.

Voici une très belle lecture qui reprend ce que je pense que vous recherchez. Ils ont pris des données d'étudiants de premier cycle en utilisant une politique de trois coups, une politique de dix coups et une politique de grèves infinies afin de suggérer que nous augmentions le nombre de trois à dix (car cela triple environ le succès de la connexion).

Revenez à une vue subjective ici ...

Pourquoi la plupart des endroits utilisent-ils une politique de trois avertissements? C'est certainement juste une heuristique qui s'est développée au fil du temps. Trois tentatives sont plus ou moins un terrain d'entente pour les administrateurs et les utilisateurs, dans la mesure où trois chances sont plus que suffisantes.

L'idée derrière un mot de passe est que vous êtes supposé le savoir . Vous ne devriez vraiment pas avoir besoin de plus d’un essai. Je comprends que des erreurs sont commises, mais dans une guerre ... vous n'avez vraiment qu'une seule chance de prouver que vous êtes un allié, n'est-ce pas?

Ils doivent en avoir choisi 3 au hasard. C'est extrêmement bas. Peut-être ont-ils eu des problèmes de sécurité dans le passé et ont choisi un faible nombre de verrouillage plutôt que de résoudre ou de résoudre le problème correctement.

Je préfère la méthode de verrouillage de l'utilisateur par incréments de temps croissants. Cependant, je ne le supprimerais pas du nom d'utilisateur, j'utiliserais plutôt l'adresse IP de la personne, car la personne pourrait essayer plusieurs noms d'utilisateur. J'ai défini le temps de verrouillage sur (nombre de tentatives de connexion non valides) ^ 2 secondes, une fois que l'utilisateur a atteint 5 tentatives non valides. Si l'utilisateur ne connaît pas son mot de passe dans un nombre relativement faible de tentatives, il utilisera principalement un outil de récupération de mot de passe si le site en fournit un. S'il s'agit d'une véritable tentative de piratage, cela deviendra tellement frustrant pour le pirate informatique qu'il finira par abandonner. Les robots essaieront tellement de fois qu'ils ne seront presque jamais autorisés à se connecter ... par exemple, s'ils essayaient 1000 mots de passe (ce qui prendrait beaucoup de temps à faire de toute façon), ils devraient attendre 11 1/2 jours avant de pouvoir essayez le 1001e mot de passe. Vous pouvez facilement augmenter la capacité de dissuasion en augmentant le multiplicateur à ^ 3. Tout ce qui précède peut devenir un peu trop élevé pour les utilisateurs humains valides.

Il n'y a pas si longtemps, j'ai implémenté un schéma de sécurité de connexion qui suivait ces règles de base:

1. La première tentative ratée donne un retour immédiat. Ils l'ont probablement fatigué.
2. De la deuxième à la cinquième tentative infructueuse, la réponse a été retardée d'une seconde par tentative ratée. par exemple. 2 secondes, 3 secondes, 4 secondes ...
3. Si la cinquième tentative échouait, la session était terminée et ils recevaient un message indiquant qu'ils devraient fermer leur navigateur et essayer à nouveau.

Pour moi, c'était plus que suffisant pour empêcher les attaques par force brute; serait tout au plus un inconvénient pour les utilisateurs finaux, et n'a pas créé de travail supplémentaire pour l'assistance.