Pourquoi n'est-il pas devenu la norme pour empêcher les tentatives répétées de mot de passe?
Tout le monde est conscient de la convention/du besoin de mots de passe forts. Avec le nombre de différents types d'indices que les gens peuvent utiliser dans leurs mots de passe, ainsi que les diverses permutations de majuscules et de substitution de lettres et de chiffres, un pirate informatique devrait faire de nombreuses tentatives en moyenne, afin d'obtenir le mot de passe réussi.
Ce lien: Ralentir les attaques de mot de passe répétées discute de certains efforts pour décourager toute cette supposition, bien que ce ne soit pas la même question que j'ai: pourquoi n'est-il pas devenu la norme d'interférer avec les suppositions répétées? Une augmentation du temps d'attente après chaque mauvaise estimation est une façon, et d'autres ont été discutées.
J'ai vu très peu de tentatives pour empêcher une telle supposition sur les systèmes Linux ou toute authentification basée sur le Web. J'ai été exclu d'un système lorsque je me suis trompé 3 fois.
Les informaticiens imposent de plus en plus de contraintes, comme le nombre de caractères, les lettres, les chiffres, les majuscules et l'exclusion du nom d'utilisateur du mot de passe. Mais cela augmente simplement le nombre de tentatives nécessaires dans une situation où le nombre n'est pas vraiment limité.
Je voudrais contester votre hypothèse selon laquelle ( cela ne se fait pas .
[avertissement: approximations sauvages à suivre]
N'oubliez pas qu'une attaque par force brute réussie nécessitera des millions ou des milliards de suppositions par seconde pour faire le crack dans un délai raisonnable (par exemple, quelques heures à un mois selon la force de votre mot de passe). Même une limite de taux de 100 tentatives de mot de passe par seconde augmenterait le temps de crack d'un mois à des centaines de milliers d'années. Peut-être que mes normes sont basses, mais c'est assez bon pour moi, et aucun utilisateur humain essayant légitimement d'accéder à son compte ne le remarquera jamais. Encore mieux si la limite de débit était par IP plutôt que par nom d'utilisateur juste pour empêcher certains types d'attaques par déni de service.
De plus, je ne sais pas quelle distribution Linux vous utilisez, mais sur mes systèmes Ubuntu et CentOS, lorsque je tape mal mon mot de passe dans les écrans de connexion de l'interface graphique ou du terminal, il se verrouille pendant 1 seconde avant de me redemander.
Même si le serveur ne limite pas activement les tentatives de connexion (ce qu'elles devraient vraiment être), seul le temps de ping suffit à lui seul pour vous ralentir à des millions d'années. Vous allez probablement DDOS le serveur avant d'obtenir près de 1 milliard de suppositions/seconde. L'argent réel consiste à obtenir une copie de la base de données de mots de passe hachés et à l'intégrer dans une plate-forme GPU où des milliards de suppositions par seconde sont possibles.
TL; DR: si vous allez vous efforcer de durcir votre serveur de connexion, vous en aurez plus pour votre argent en améliorant le hachage de votre mot de passe et en rendant votre base de données difficile à voler qu'en appliquant le taux -limitation sur votre écran de connexion.
UPDATE : Depuis que cela est devenu viral, je vais tirer quelque chose des commentaires:
Cette logique s'applique uniquement aux serveurs de connexion. Pour les appareils physiques tels que les téléphones ou les ordinateurs portables, une chose de type "3 tentatives et il se verrouille" ou "10 tentatives et la réinitialisation de l'appareil" a toujours du sens parce que quelqu'un pourrait surfer pendant que vous tapez votre mot de passe, ou voir le motif de maculage sur votre écran, ou sachez qu'un code à quatre chiffres PIN n'a que 10 000 combinaisons de toute façon, donc le nombre de suppositions à faire est très très beaucoup plus petit.
Il y a un problème important avec le verrouillage des personnes après des tentatives répétées non valides - cela devient en fait un vecteur d'attaque pour un type d'attaque par déni de service. Pensez à ce qui pourrait arriver à un service d'assistance ou à un site de service client si quelques centaines de milliers de comptes se retrouvent tous verrouillés de manière cohérente par quelqu'un qui tente de perturber un service.
Il y a même un site Web que j'utilise qui m'envoie un courrier physique à chaque fois que je change de mot de passe - une personne particulièrement méchante pourrait vraiment créer des problèmes en trouvant une liste de comptes et en les suspendant à plusieurs reprises.
Il y a certainement un jugement à faire entre la sécurité et la convivialité, et je ne pense pas personnellement qu'il y ait une réponse fixe ou tapotée.
Une complexité suffisante rend la technologie brute impossible à appliquer à la force brute, le ralentir ne ferait pas grand-chose de plus.
"Mais cela augmente simplement le nombre de tentatives nécessaires" est une façon étrange de dire des milliards d'années de plus.
Vous supposez que les mots de passe ne peuvent être vérifiés qu'en utilisant la connexion. Mais assez souvent, il y a une fuite de données/piratage qui permet à quelqu'un d'obtenir les tables de hachage du mot de passe. S'il en a, il peut simplement utiliser la force brute pour les hachages, ce qui est plusieurs fois plus rapide que d'utiliser la connexion. Et c'est là que vous avez vraiment besoin de bons mots de passe.
Un concept très important que je ne vois pas mentionné dans les autres réponses jusqu'à présent est la différenciation entre la force brute hors ligne et en ligne.
Dans bruteforce hors ligne, l'attaquant a accès aux mots de passe hachés et ici, la principale défense utilise un algorithme de hachage de mot de passe approprié (par exemple, bcrypt). les points autour des algorithmes de hachage, le craquage du GPU, etc., ne concernent que la force brute hors ligne
Je suppose que cette question concerne la bruteforce en ligne où l'attaquant tente de se connecter au système à distance.
Avec les connexions à distance pour des services tels que SSH, comme cela a été mentionné, la recherche de mot de passe à distance est généralement inhibée par fail2ban ou similaire.
Là où ce n'est pas courant, c'est dans les applications Web (je sais parce que je donne assez souvent aux propriétaires d'applications Web des lacunes sur cette fonctionnalité).
Un verrouillage direct est configuré dans certains systèmes, mais cela fait face au risque de déni de service d'attaques de devinettes de mot de passe d'attaquants et également à certains inconvénients pour les utilisateurs en fonction du mécanisme de réactivation des comptes.
Une meilleure solution est de forcer un retard croissant dans les tentatives de connexion pour rendre l'attaque moins réalisable, mais il est important de noter que dans certains cas, un attaquant peut simplement vouloir compromettre un compte (et ne se soucie pas vraiment de qui il obtient), auquel cas il peut simplement essayer un petit nombre de mots de passe courants dans la base d'utilisateurs, dans l'espoir que quelqu'un les aura utilisés.
La manière la plus simple de voir cela est avec une autre question. Pourquoi SHA-1/MD5 est-il toujours utilisé alors qu'il présente des failles/problèmes connus?
En termes simples, l'évaluation des risques de l'individu/société considère que ces questions ne sont pas une préoccupation majeure. Tout comme dans le cas des délais d'attente de roulement.
Quand je faisais de l'administration pour une école locale, il était assez courant pour les enseignants de "deviner" leurs propres mots de passe. Forcer les enseignants à attendre était beaucoup plus gênant, puis simplement verrouiller un compte après 4 ou 5 mots de passe incorrects et leur demander de me téléphoner pour le déverrouiller.
Les délais d'attente de roulement sont également une douleur majeure à gérer. Pour un système local, ce n'est peut-être pas un problème, mais prenez l'exemple de mon école (comme ci-dessus) ou d'une grande entreprise de plus de 1 000 employés. Le travail ne peut plus être effectué car quelqu'un est assis à une invite de mot de passe, attendant la chance d'entrer le mot de passe correct. Peut-être que quelqu'un a pensé qu'il serait drôle de demander à quelqu'un de s'asseoir à une invite pendant quelques heures, ou qu'un attaquant voulait ralentir la production? Tenez compte du fait qu'il doit y avoir un moyen d'administrer la durée des délais d'expiration, leur augmentation et un moyen de les réinitialiser.
Je dirais qu'un système de verrouillage, tel que celui autorisé par Windows, est en fait plus sûr. Il nécessite une intervention administrative et peut être beaucoup plus rapide à annuler (plus le temps nécessaire pour consulter les journaux). Sur un système basé sur le Web, un délai d'attente de roulement pourrait être plus avantageux, mais comme nous l'avons déjà vu, les hachages de mot de passe seront divulgués et les délais d'attente de roulement ne seraient d'aucune utilité.