Question:
Pourquoi n'est-il pas devenu la norme d'empêcher les devinettes répétées de mot de passe?
donjuedo
2017-02-01 04:02:16 UTC
view on stackexchange narkive permalink

Tout le monde est conscient de la convention / du besoin de mots de passe forts. Avec le nombre d'indices que les gens peuvent utiliser dans leurs mots de passe, ainsi que les différentes permutations de majuscules et de substitution de chiffres-lettres, un pirate informatique devrait faire de nombreuses tentatives en moyenne pour obtenir le mot de passe réussi.

Ce lien: Ralentir les attaques répétées de mot de passe traite des efforts pour décourager toutes ces suppositions, même si ce n'est pas la même question que je me pose: pourquoi n'est-il pas devenu la norme d'interférer avec des suppositions répétées? Un temps d'attente croissant après chaque mauvaise estimation est un moyen, et d'autres ont été discutés.

J'ai vu très peu de tentatives pour empêcher de telles suppositions 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é.

Citation requise!De nombreux systèmes implémentent des régulateurs, bien qu'ils puissent être silencieux plutôt qu'avec un verrouillage explicite;ils peuvent également être des régulateurs de demande de site généraux plutôt que d'être spécifiques à la connexion.Pour ssh (qui a déjà des retards intégrés), voyez aussi la popularité de fail2ban.Je soupçonne que la raison pour laquelle vous ne rencontrez pas souvent de verrouillages est qu'ils sont * bien réglés * pour ne pas déclencher le comportement normal des utilisateurs, et que vous n'essayez pas activement et constamment de pirater les comptes d'utilisateurs.
La mesure d'une bonne sécurité est la mesure dans laquelle elle ** fait la distinction ** entre un utilisateur légitime et un utilisateur malveillant.Un système de sécurité qui verrouille un utilisateur légitime hors de son compte ne répond pas aux critères de disponibilité de la triade CIA (confidentialité, intégrité et disponibilité).Une bonne politique de verrouillage des comptes doit être conçue de manière à ce qu'ils ne soient jamais rencontrés par des utilisateurs légitimes.Si tout ce qui compte est de garder les méchants à l'écart, quel que soit le coût pour les utilisateurs légitimes, j'ai le meilleur système de sécurité au monde: `function login (un, pw) {return" Désolé, mauvais mot de passe ";} `.
Ajoutant aux commentaires précédents, ces manettes seront silencieuses pour éviter d'aider les attaquants à savoir exactement quelles protections sont utilisées.
Il est assez courant que les systèmes renvoient leur message normal "nom d'utilisateur ou mot de passe incorrect" une fois qu'un compte est verrouillé - sinon, vous indiquez si un compte existe, à moins que vous ne suiviez chaque nom d'utilisateur saisi et ne répondiez de manière identique.
@LieRyan par exemple, le nouveau système captcha signifie qu'un véritable humain ne devrait pas souvent avoir à choisir parmi les photos
@LieRyan: J'ai appris la CIA en tant que «confidentialité» (personne d'autre ne peut la lire), «intégrité» (je lis ce qui a été envoyé) et «authenticité» (cela vient vraiment de qui je pense).
AilizejrmsCMT https://en.wikipedia.org/wiki/Information_security#Availability
«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.» Citation nécessaire.Normalement, ce sont les patrons aux cheveux pointus qui ajoutent des "exigences de force" stupides de mot de passe.https://xkcd.com/936/
La force du mot de passe est également importante pour les hacks dans lesquels le pirate a obtenu une liste hachée de mots de passe.Si le mot de passe de tout le monde était mauvais, la force de la fonction de hachage serait moins importante.
Je ne suis pas sûr d'être d'accord avec le sentiment que "tout le monde est conscient de la nécessité de mots de passe forts".Regardez n'importe quel vidage de mot de passe des violations récentes et je vous garantis que vous y trouverez une grande proportion de mots de passe triviaux ...
Pourquoi les gens utilisent-ils toujours MD5 pour le hachage de mot de passe?Parce qu'ils ne savent pas mieux ou s'en [email protected] "Authenticité" ferait partie de "l'intégrité" selon votre propre définition.
Six réponses:
#1
+113
Mike Ounsworth
2017-02-01 04:08:47 UTC
view on stackexchange narkive permalink

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 est intéressant de penser que certains systèmes donnent peut-être l'apparence * que cela n'est pas fait pour atténuer le risque de DOS et identifier les méchants (c'est peut-être ce que vous vouliez dire, Mike?) Par opposition aux systèmes implémentant couramment des verrouillages.
@symcbean Je ne pensais pas vraiment au pot de miel.Mon point était plus qu'un "verrouillage" de 10 millisecondes suffit pour arrêter une attaque par force brute, alors pourquoi déranger vos utilisateurs sans raison?Maintenant, pour les téléphones et les PC avec des taches sur l'écran ou les personnes qui regardent par-dessus votre épaule, il y a peut-être un argument pour un verrouillage après 3, mais le PO posait spécifiquement des questions sur les serveurs Web.
Sur Linux, en particulier les configurations de serveur, il existe un service appelé le démon d'échec de connexion (LFD).Au lieu de désactiver une connexion, LFD interdit temporairement l'adresse IP qui tente de se connecter.
@MikeOunsworth Un verrouillage après 3 est totalement irréalisable à moins que l'appareil ne soit géré de manière centralisée et permette un déverrouillage via une informatique d'entreprise ou autre, et même dans ce cas, c'est compliqué dans la pratique.Les gens saisissent mal les mots de passe plus de 3 fois trop souvent, surtout dans les cas où le changement de mot de passe est imposé.
DDOS = attaque par déni de service distribué.Vous ne pouvez pas faire ça seul.
@JanDvorak C'est exactement ce que je veux dire: il n'y a aucun moyen qu'un seul ordinateur puisse générer près d'un milliard de demandes de connexion par seconde.
@DRF D'après mon expérience, 3 à 5 tentatives de verrouillage sont en fait une pratique assez courante.L'annonce de mon entreprise actuelle est définie sur 3. Je pense que j'ai eu besoin de l'administrateur Internet pour déverrouiller mon compte une ou deux fois en plus de 8 ans.J'ai également dû demander à l'administrateur Internet de déverrouiller les comptes d'autres utilisateurs qui tentaient de se connecter à un service Web que j'ai écrit plusieurs fois au cours de cette période.Par défaut, mon téléphone Samsung efface en fait la mémoire du téléphone si le mot de passe est mal saisi 10 fois.À en juger par la situation avec le FBI dans l'affaire du tireur de San Bernardino, iOS utilise apparemment le même défaut.
Cela suppose en grande partie que le but est de compromettre un mot de passe spécifique, et pas seulement "le mot de passe de n'importe qui".Dans ce cas, l'attaquant (après avoir énuméré les comptes d'utilisateurs), vient d'essayer tous les comptes avec "Password1" ou équivalent et part de là, obtenant probablement l'accès avec un nombre relativement faible de suppositions (par rapport aux nombres nécessaires pour une force brute deun compte), cela est plus pertinent dans les applications Web que dans les boîtes Linux, où il y aura probablement une grande population d'utilisateurs.
RoryMcCune Si vous utilisez fail2ban, ou autre chose pour limiter le débit en fonction de l'IP plutôt que la limite du débit en fonction du nom d'utilisateur demandé, cela ne revient-il pas au même?
Sans oublier qu'un verrouillage comme celui-ci peut facilement devenir une attaque DOS lui-même - tout ce que vous avez à faire est de trouver les noms d'utilisateur des utilisateurs du service, et de "deviner" trois mauvais mots de passe et le tour est joué - le service n'est plus utilisable.Particulièrement efficace si les administrateurs n'ont pas d'accès spécial, ils ne peuvent donc pas inverser les verrouillages: P
#2
+60
Ken Whitesell
2017-02-01 06:22:34 UTC
view on stackexchange narkive permalink

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.

N'essaieriez-vous pas de verrouiller la machine (IP source) au lieu de l'utilisateur qui est utilisé?De cette façon, un attaquant devrait pouvoir (prétendre) provenir de la même adresse IP que l'utilisateur légitime.Maintenant, bien que cela soit possible, je pense que cela devrait être beaucoup plus difficile ...
Les réseaux Bot @Thomas signifient que vous pouvez utiliser des milliers ou des millions d'adresses IP pour essayer de vous connecter à un compte.
@Thomas Et comment stockez-vous ces informations?Si j'ai un botnet avec dix mille ordinateurs et que je verrouille tous les utilisateurs du système à partir de dix mille machines différentes, votre système va-t-il survivre?Quelle est la chance que j'ai réussi à bloquer également certains utilisateurs légitimes (NAT et autres)?Comment l'utilisateur peut-il éventuellement dire pourquoi il ne peut plus accéder à son compte, en particulier lorsqu'une bonne pratique de sécurité consiste à éviter de dire à l'utilisateur que son compte a été verrouillé?Votre service peut-il gérer cela?
Curieusement, [Stack Exchange lui-même a été utilisé pour une attaque d'inondation de mot de passe réinitialisée] (http://meta.stackexchange.com/questions/270051/please-rate-limit-the-password-reset-functionality)
@Luaan "C'est toujours quelque chose" (RFC 1925)
#3
+5
Slava Knyazev
2017-02-01 04:08:21 UTC
view on stackexchange narkive permalink

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.

Le ralentissement que j'imaginais pourrait être 1 seconde supplémentaire après le premier échec, puis 2 secondes, puis 4, puis 8 et ainsi de suite.Bien sûr, cela doit être réinitialisé une fois que certains critères sont satisfaits.Avec un tel niveau de retard, même un mot de passe modeste me semblerait suffisant (pour moi, novice).
@donjuedo Mais dans quel but?Avec suffisamment de complexité, cela n'a tout simplement pas d'importance.Le serveur sera un fossile au moment où il l'obtiendra.
C'est dans le but de se souvenir des mots de passe plus faciles, tout en maintenant la sécurité.
Alors pour utiliser des mots de passe moins complexes?C'est simplement une mauvaise idée, peu importe comment vous la regardez.
Nous comparons (mots de passe complexes devinés à grande vitesse) à (mots de passe moins complexes devinés à basse vitesse).Ni l'un ni l'autre n'est intrinsèquement meilleur que l'autre.Ce qui est important, c'est ce que vous avez dit, "impraticable à bruteforce", ou le temps prévu pour craquer est trop long.
les mots de passe complexes devinés à haute vitesse SONT intrinsèquement meilleurs cependant.La vitesse est linéaire, la complexité est exponentielle.
C'est une sorte de réponse «blâmez la victime».Choisir un mot de passe entropique est une bonne mesure, mais que les * utilisateurs * adoptent pour se protéger des attaquants.En revanche, la limitation des tentatives de connexion est une mesure que * les développeurs * et * les administrateurs * prennent pour protéger les utilisateurs contre les attaquants * et eux-mêmes *.Les développeurs et les administrateurs ne peuvent pas sauver * tous * les utilisateurs de leurs propres mauvais choix, mais nous avons la responsabilité de fournir des garanties raisonnables.
@donjuedo qui ne protégera que le mot de passe faible contre le bruteforcing * via ce canal unique *.Si par exempleles hachages salés sont divulgués d'une base de données, alors les mots de passe faibles seraient vulnérables au bruteforcing «autour» du serveur et de la manette des gaz, tandis que les mots de passe forts seraient toujours protégés.
#4
+4
Goodbye SE
2017-02-02 15:48:24 UTC
view on stackexchange narkive permalink

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.

#5
+2
Rory McCune
2017-02-02 19:48:03 UTC
view on stackexchange narkive permalink

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.

Votre hypothèse sur la question liée à la force brute en ligne est correcte.Quand j'ai posté, je n'avais même pas envisagé une attaque hors ligne, et je ne l'ai remarqué qu'après avoir été mentionnée ici et là.
#6
+1
dark_st3alth
2017-02-01 04:20:40 UTC
view on stackexchange narkive permalink

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é.

En fait, l'écran de connexion Windows * a * un retard.Vous obtenez quelques tentatives gratuites, puis cela commence à ajouter des délais supplémentaires.(Je suis tombé sur ceci, lorsque j'essayais de me connecter avec un clavier différent.)
@MartinBonner Cela se produira après la 3e (ou 5e?) Mauvaise entrée, où il y a un retard important.Si je me souviens bien, il n'y a pas de fonction "roulante", le délai ne devient pas de plus en plus long.Là encore, à ce stade, un verrouillage de compte doit être déclenché.
Les verrouillages ont cependant leurs risques, en particulier lorsqu'un attaquant est distant, c'est-à-dire qu'il est assez facile pour eux de faire un DoS le service, surtout si le format du nom d'utilisateur est connu.
Le verrouillage de compte @dark_st3alth n'a de sens que dans un domaine.Alors qu'une bonne partie des machines Windows fonctionnent dans un domaine, vous ne pouvez pas vraiment ignorer tous les ordinateurs qui ne le font pas.Comment un utilisateur n'appartenant pas au domaine se rétablirait-il du verrouillage?


Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...