Je voudrais contester votre hypothèse selon laquelle n'est pas effectuée.

[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 laps de temps 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 ferait passer le temps de crack d'un mois à des centaines de milliers d'années. Peut-être que mes normes sont faibles, mais cela me suffit, 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 saisis mal mon mot de passe sur les écrans de connexion de l'interface graphique ou du terminal, il se verrouille pendant 1 seconde avant de me demander à nouveau.

Même si le serveur n'est pas actif tentatives de connexion limitant le débit (ce qu'elles devraient vraiment être), le temps de ping suffit à lui seul pour vous ralentir à des millions d'années. Vous aurez probablement DDOS le serveur avant d'arriver à 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'insérer dans une plate-forme GPU où des milliards de suppositions par seconde sont possibles.

TL; DR: si vous l'êtes vous ferez des efforts pour renforcer 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 implémentant une limitation de débit sur votre écran de connexion.

MISE À JOUR : comme cela est devenu viral, je vais tirer quelque chose des commentaires:

Cette logique ne s'applique qu'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 l'appareil essuie» a toujours du sens, car quelqu'un pourrait surfer sur l'épaule pendant que vous tapez votre mot de passe ou voir le motif de bavure sur votre écran, ou sachez qu’un code PIN à 4 chiffres n’a de toute façon que 10 000 combinaisons, de sorte que le nombre d’évaluations nécessaires est très beaucoup plus petit.

Il y a un problème important avec le verrouillage des personnes après des tentatives non valides répétées: 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 essayant de perturber un service.

Il y a même un site Web que j'utilise. m'envoie un e-mail 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 définitivement un jugement à faire entre la sécurité et convivialité, et je ne pense pas personnellement qu’il y ait de réponse fixe ou parfaite.

Une complexité suffisante rend la force brute technologiquement irréalisable, le ralentir ne ferait pas beaucoup 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 le login, mais il y a assez souvent 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 le login. 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.

En 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, du craquage de GPU, etc., ne concernent que la force brute hors ligne

Je suppose que cette question concerne la force brute en ligne où l'attaquant tente probablement de se connecter au système à distance.

Avec les connexions à distance pour des services comme SSH, comme cela a été mentionné, la devinette 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 aux propriétaires de résultats des applications Web pour le manque de cette fonctionnalité assez fréquemment).

Un verrouillage direct est mis en place dans certains systèmes, mais cela fait face au risque de déni de service de la part des attaquants qui tentent de deviner le mot de passe et également à certains inconvénients pour l'utilisateur en fonction du mécanisme de réactivation des comptes.

Une meilleure solution est de forcer un délai croissant dans les tentatives de connexion pour rendre l'attaque moins faisable, mais il est important de noter que dans certains cas, un attaquant peut simplement vouloir compromettre un compte (sans vraiment se soucier du compte qu'il obtient) dans lequel dans le cas où ils peuvent simplement essayer un petit nombre de mots de passe communs dans la base d'utilisateurs, dans l'espoir que quelqu'un les aura utilisés.

Le moyen le plus simple de voir cela est de poser une autre question. Pourquoi SHA-1 / MD5 est-il toujours utilisé alors qu'il présente des défauts / problèmes connus?

En termes simples, l'évaluation des risques de l'individu / de l'entreprise considère que ces problèmes ne sont pas une préoccupation majeure. Tout comme dans le cas des délais d'attente.

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 verrouiller un compte après 4 ou 5 mots de passe incorrects et les faire me téléphoner pour le déverrouiller.

Les délais d'attente sont également un problème majeur. 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 fait parce que 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 amusant de faire asseoir quelqu'un à 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, de combien ils augmentent de, et un moyen de les réinitialiser.

Je dirais qu'un système de verrouillage, tel que celui-ci, permettait par Windows, est en fait plus sécurisé. 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 déploiement pourrait être plus avantageux, mais comme nous l'avons déjà vu, les hachages de mots de passe seront divulgués et les délais d'expiration ne seraient d'aucune utilité.