Pourquoi les sites implémentent-ils le verrouillage après trois tentatives de mot de passe infructueuses?
Je connais le raisonnement derrière ne pas laisser des tentatives de mot de passe infinies - les tentatives de force brute ne sont pas une faiblesse meatspace , mais un problème de sécurité informatique - mais d'où ont-elles obtenu le numéro trois?
Le déni de service n'est-il pas un problème lors de la mise en œuvre d'une politique de verrouillage facilement activable?
Existe-t-il des recherches approfondies montrant un nombre ou une plage optimale à choisir avant de verrouiller un compte qui équilibre la menace de sécurité réelle avec la convivialité?
En y réfléchissant, je ne vois aucune différence de sécurité mesurable entre trois tentatives et 20 tentatives avec la complexité du mot de passe généralement utilisée aujourd'hui.
(Je connais cette subjectivité des jupes, mais je recherche des opinions basées sur des mesures)
Récemment, lors de la conférence OWASP AppSec 2010 dans le comté d'Orange, Bill Cheswick d'AT & T a longuement parlé de cette question.
Bref, les recherches sont insuffisantes.
En bref, voici quelques-unes de ses idées pour un verrouillage de compte moins douloureux:
- Ne comptez pas les tentatives de mot de passe en double (ils pensaient probablement l'avoir mal saisi)
- Faites un indice de mot de passe sur le mot de passe principal et n'avez pas de secondaire (faible)
- Autorisez un tiers de confiance à se porter garant de l'utilisateur afin qu'il puisse modifier son mot de passe.
- Verrouillez le compte par incréments de temps croissants
- Rappelez à 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 pas plus de six tentatives)
- 8.5.14 (Définissez la durée de verrouillage sur trente minutes ou jusqu'à ce que l'administrateur active l'ID utilisateur).
C'est malheureusement pourquoi 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 ne s'appliquent qu'aux systèmes destinés aux "utilisateurs non consommateurs", de sorte qu'elles ne devraient pas affecter les sites clients acceptant les cartes.
D'après mon expérience, les mécanismes de verrouillage diminuent en popularité (au 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 provenait de la règle des trois frappes de baseball plutôt que de quelque chose de technique.
Une justification (pour les mots de passe alphanumériques de toute façon) est
En général, une tentative échouée est soit un problème de type, soit un problème d'activation/désactivation de CAPS. Donc, vous essayez de vous connecter et d'être rejeté (1), réessayez parce que vous pensez que vous avez mal tapé (2), puis réalisez que la touche CAPS est activée, vous entrez donc dans la troisième tentative.
Ne vaut pas vraiment pour déverrouiller les téléphones mobiles d'un réseau alors qu'il s'agit généralement d'un code numérique saisi.
De meilleures suggestions sont un délai sans cesse croissant entre les tentatives de connexion échouées successives. D'abord, vous autorisez une nouvelle tentative instantanée, puis 1 seconde, 2, quatre, huit ... Vous attendez rapidement une minute entre les tentatives, ce qui est suffisant pour organiser toute attaque par force brute.
Je suis d'accord avec l'OP. Si vous pensez à ce que le verrouillage vous protège, il n'y a pas de différence entre 3 ou 20 tentatives (ou 100, d'ailleurs). Tout ce que vous réalisez avec ces verrouillages, en plus de punir les utilisateurs oublieux, est d'empêcher une attaque par force brute. Vous pouvez également l'utiliser pour déclencher un avertissement 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 des DoS à vos utilisateurs juste pour faciliter votre propre travail de surveillance. Ce n'est pas un très bonne pratique).
Si quelqu'un possède votre base de données de mots de passe et peut le pirater hors ligne, il dispose d'un nombre illimité d'essais. 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 sur cette liste. Si vous autorisez 20 tentatives de mot de passe, disons toutes les 15 minutes, sans verrouillage, il faudra plus de deux heures à un attaquant pour parcourir cette liste.
En fait, même si vous restreignez votre liste de devinettes aux 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, étendant une attaque par dictionnaire à peut-être une heure ou plus. Cette supposition constante et erronée au fil du temps est ce qui devrait déclencher vos alarmes, pas une poignée de mauvais mots de passe en quelques minutes.
Donc, si vous pouvez éloigner vos utilisateurs des pièges de mot de passe les plus élémentaires, vous pouvez accepter volontiers 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 suspendu quelque part avec d'anciennes informations d'identification. Et si ce n'est pas le cas, alors nous pouvons parler de la recherche d'attaques.
C'est une règle arbitraire idiote qui comporte le risque d'une étrange sorte d'attaque DDOS. Disons que Marv déteste le site Web X et que le site Web X a une politique de verrouillage du nombre Y. Marv pourrait soulever un enfer grave en ayant un script essayer automatiquement des noms aléatoires Y fois avec des mots de passe faux. Même si un mot de passe fonctionnait, Marv ne s'en soucierait probablement pas et l'ignorerait. Cela verrouillerait efficacement de nombreux utilisateurs du site Web X et causerait beaucoup de frustration, et Dieu les aide s'ils sont la 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 stratégie de verrouillage du compte (avec le nombre de tentatives non valides consécutives généralement dans la plage de chiffres uniques pour la plupart des organisations) n'a pas été conçue uniquement contre les attaques automatisées par force brute.
Il s'agit davantage d'une protection contre la tentative de mot de passe par des attaquants humains, en particulier par des personnes qui connaissent déjà une partie du mot de passe. Les attaquants pourraient obtenir des fragments de mot de passe en
- surf à l'épaule
- en devinant les schémas 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, c'est qu'avec une valeur seuil basse, il y aura forcément un déni de service et un coût associé pour les entreprises. Le Livre blanc sur les meilleures 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 stratégie de verrouillage de compte de Windows:
Par 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 définie sur 20, l'utilisateur malveillant a 20 suppositions à utiliser contre cela. mot de passe. Si la durée de verrouillage est de 30 minutes, l'utilisateur malveillant a 20 suppositions toutes les 30 minutes contre ce mot de passe jusqu'à ce qu'il soit modifié. Il s'agit d'une différence très importante 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 par rapport à un mot de passe donné, tandis que le deuxième utilisateur malveillant a 40320 suppositions (20 tentatives de verrouillage pour toujours, 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 y a environ 10 ^ 12 mots de passe possibles. Cela signifie que l'utilisateur malveillant a environ une chance de .000004 pour cent (%) 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 examinées. Par conséquent, on peut supposer sans risque 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 le mentionnez, empêche les attaques par force brute.
À cet effet, un nombre quelconque d'essais devrait vraiment être fait - 3, 5, 20, 2000 ... avec une politique de mot de passe appropriée (longueur + complexité + ...) donnant un espace clé suffisamment grand, n'importe quoi le type de limitation (X nombre d'essais par heure) garantira que le forçage brutal de l'espace entier prendra 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 de temps, il se déverrouille automatiquement.
Ainsi, le nombre d'essais avant verrouillage est arbitraire.
Cependant, il y a un autre problème non mathématique plus subtil en jeu ici:
Cela n'a tout simplement pas de sens pour un seul utilisateur de saisir à plusieurs reprises un mauvais mot de passe 2000 fois de suite.
Autrement dit, si vous choisissez arbitrairement 2000, vous savez longtemps avant cela que ce n'est PAS un utilisateur légitime. Ainsi, cela se résume vraiment à ce qui est logique pour l'entreprise et à un compromis d'analyse des risques axé sur les entreprises.
Je pense qu'historiquement, le compromis était plus orienté vers le côté 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 mots de passe, donc ils étaient plus faciles à retenir ... Et, les utilisateurs étaient plus techniquement avertis en général.
De nos jours, trois n'a vraiment aucun sens, compte tenu de l'impact sur les entreprises. C'est vraiment une question de savoir ce qui a du sens pour l'application votre, 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 doubler il.
( Comme l'a mentionné @realworldcoder , PCI en a choisi arbitrairement six, et si vous êtes soumis à PCI, vous n'avez pas beaucoup de décision ici. Sinon, choisissez un nombre qui vous convient.)
En ce qui concerne les suggestions d'incrémentation temporelle des `` verrouillages '' pour retarder les tentatives infructueuses successives et donc 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 d'accéder au système, il peut effectuer une première attaque étendue (faire défiler tous les noms d'utilisateurs connus/devinés avant de passer au mot de passe suivant). Ajoutons que si cela a été fait correctement, il pourrait provenir d'un réseau distribué de machines, il est assez facile de voir que le système de retard ne fonctionne pas non plus.
Comme mentionné par d'autres, une surveillance correcte des tentatives infructueuses de découverte précoce des attaques est essentielle.
Oui, 3 tentatives sont assez arbitraires et posent un risque DoS. Je souhaite vraiment que les gens cessent d'utiliser des systèmes pour le public ... S'il vous plaît!
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 ainsi que le mot de passe pour se connecter.
Mais cela pose un tout autre tas de problèmes pour la mise en œuvre et la confiance ...
Les sociétés ouvertes (vendant des actions en bourse) sont réglementées par la loi Sarbanes-Oxley et sont vérifiées plusieurs fois par an pour vérifier leur conformité. Les applications logicielles critiques doivent respecter certaines fonctions de sécurité, notamment pour verrouiller les comptes après l'échec des tentatives de mot de passe.
La majorité de ces applications ce qu'elles font est d'intégrer dans la société Active Directory qui ont déjà les fonctionnalités activées.
Voici une lecture vraiment sympa qui va sur ce que je crois que vous recherchez. Ils ont pris des données sur les étudiants de premier cycle utilisant une politique à trois grèves, une politique à dix grèves et une politique à grève infinie afin de suggérer que nous augmentions le nombre de trois à dix (car cela triple approximativement le succès de la connexion).
Revenons à une vue subjective ici ...
Pourquoi la plupart des endroits utilisent-ils une politique de trois grèves? Ce n'est certainement qu'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, en ce sens que trois chances sont plus que suffisantes.
L'idée derrière un mot de passe est que vous êtes supposé le connaître. 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é, non?.
Ils doivent 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 numéro de verrouillage faible plutôt que de résoudre ou de résoudre correctement le problème.
Je préfère la méthode de verrouillage de l'utilisateur par incréments de temps croissants. Je ne voudrais pas le supprimer du nom d'utilisateur, mais plutôt utiliser l'adresse IP de la personne, car la personne pourrait essayer plusieurs noms d'utilisateur. J'ai défini le délai 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 si frustrant pour le pirate qu'il finira par abandonner. Les bots essaieront tant de fois qu'ils ne seront presque jamais autorisés à se connecter ... par exemple, s'ils essayaient 1000 mots de passe (ce qui prendrait du temps à le faire), 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 est au-dessus pourrait 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 a suivi ces règles de base:
- La première tentative échouée donne un retour immédiat. Ils l'ont probablement touché la graisse.
- De la deuxième à la cinquième tentative infructueuse, la réponse a été retardée d'une seconde par tentative infructueuse. par exemple 2 secondes, 3 secondes, 4 secondes ...
- Si la cinquième tentative a échoué, la session a pris fin et un message leur a été indiqué indiquant qu'ils devaient fermer leur navigateur et réessayer.
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 le support.