Question:
Pourquoi les attaques de craquage de mots de passe par force brute ne sont-elles pas automatiquement détectées et contrecarrées?
kjo
2014-06-26 18:31:16 UTC
view on stackexchange narkive permalink

Pourquoi le logiciel ne détecte-t-il pas automatiquement les attaques de piratage de mots de passe et ne les contrecarre-t-il pas?

Version longue:

Supposons que quelqu'un tente un piratage de mot de passe par force brute attaque sur un programme XYZ nécessitant une authentification par mot de passe.

Je crois comprendre qu'une telle attaque consisterait à parcourir l'ensemble de "tous les mots de passe possibles", en fournissant chacun à son tour à XYZ, jusqu'à ce que l'un d'eux fonctionne . Pour que cette stratégie ait une probabilité de succès, l'attaquant devrait être capable de fournir à XYZ de très nombreux mots de passe candidats par seconde. Par conséquent, il serait trivial de programmer XYZ pour détecter ce modèle (c'est-à-dire de le distinguer du cas où un utilisateur légitime saisit le mot de passe correct plusieurs fois) et d'augmenter automatiquement l'exigence d'authentification pour les 10 minutes suivantes, par exemple.

L'idée est que le propriétaire de XYZ serait autorisé à définir deux "mots de passe": un "mot de passe de niveau 1" (AKA "le mot de passe i > ") qui est relativement facile à retenir et à taper, mais aussi relativement facile à déchiffrer par force brute, et un" mot de passe de niveau 2 "(AKA" la phrase ") qui pourrait être extrêmement long, impossible à déchiffrer par la force brute, mais aussi très gênant pour un usage quotidien (légitime).

Quelqu'un qui connaissait le mot de passe pratique mais faible mot n'aurait presque jamais besoin de utilisez la phrase de passe incassable mais peu pratique.

Je suis sûr qu'il y a une énorme faille dans ce schéma, sinon les mots de passe ne seraient pas le casse-tête des utilisateurs légitimes. Quelle est l'explication?

Il n'y a pas de mot de passe "impossible à déchiffrer par force brute". Cela prendra peut-être très très longtemps, mais le jour où le mot de passe sera craqué. BTW votre ensemble de "tous les mots de passe possibles" est (théoriquement) infiniment.
http://arstechnica.com/security/2013/05/how-crackers-make-minced-meat-out-of-your-passwords/ Les mots de passe sont toujours vulnérables aux attaques par dictionnaire, vous ne pouvez donc pas être trop paresseux avec eux .
La question est un peu trop générique, vous avez donc plusieurs types de réponses. Faites-vous référence aux serveurs Internet, aux serveurs LAN ou aux logiciels locaux?
Copie possible de cette [question] (http://security.stackexchange.com/questions/47103/cant-brute-force-password-cracking-somehow-be-throttled).
@wumm Il n'y a rien de mal à itérer sur un ensemble infini :) Comme aucun mot de passe lui-même n'a un nombre infini de caractères, vous l'itérerez éventuellement
@wumm: vous rendez-vous compte à quel point les messages deviennent totalement illisibles lorsqu'ils tentent d'anticiper et de couvrir des chicots comme les vôtres?
Non, je n'avais pas réalisé qu'écrire «presque impossible» et «essayer toutes les combinaisons» serait plus illisible. Je suis désolé pour vous que vous ne compreniez pas une note bien intentionnée.
Avec tout le reste, gardez à l'esprit que si un méchant a un réseau de robots, il peut faire la tentative via plusieurs bots, de sorte qu'aucune adresse IP ne recueille trop de tentatives infructueuses.
Cinq réponses:
AJ Henderson
2014-06-26 18:44:50 UTC
view on stackexchange narkive permalink

Raisonnablement souvent, ils le font. Tout système raisonnable vous bloquera si vous faites trop d'attaques en ligne (ou de tentatives incorrectes légitimes) pour accéder au compte.

Le problème vient des attaques hors ligne. Le serveur (ou tout ce que vous authentifiez également) doit avoir quelque chose à quoi comparer le mot de passe. Il s'agit généralement d'une valeur chiffrée qui peut être déchiffrée avec le mot de passe ou d'un hachage. Si cette valeur est compromise, par exemple lorsqu'un attaquant accède à la base de données des utilisateurs, il peut alors essayer d'exécuter le hachage ou le décryptage sur son propre ordinateur et de contourner tous les décomptes du nombre de tentatives d'essais. Ils peuvent également essayer de deviner des ordres de grandeur plus rapidement car ils travaillent localement et n'ont pas à attendre un réseau.

Avec une attaque hors ligne, il est possible de tenter des milliers, voire des millions d'attaques par seconde et il devient soudainement trivial d'attaquer des mots de passe simples en quelques minutes, voire quelques secondes. Il n'y a aucun moyen d'empêcher l'attaque puisque nous n'avons aucun contrôle sur le système utilisé pour vérifier le mot de passe. C'est pourquoi il est important de changer votre mot de passe après la découverte d'un compromis DB.

Eh bien ... pas "surtout". Des systèmes raisonnables, bien sûr - mais ce n'est pas "la plupart" ... ;-)
@AviD - juste point, est-ce que "Raisonnablement souvent" est plus en accord avec la réalité?
Cela nécessite que le pirate sache quand un mot de passe candidat est le bon, * sans * le fournir à XYZ. Le seul moyen que je puisse trouver est que, en trouvant la bonne "clé" (quelle qu'elle soit), un fichier crypté soit décodable en quelque chose de "lisible par l'homme" / "reconnaissable" (par exemple, les mots du dictionnaire, les noms personnels, etc.). Dans l'affirmative, l'attaque serait contrecarrée si le fichier "décodé" ne contenait que des chaînes qui ne sont pas plus "reconnaissables" que celles de la version codée. Bien entendu, les mots de passe «aléatoires» ne sont pas pratiques. Je veux simplement m'assurer de bien comprendre votre réponse.
@kjo - la valeur décodée doit être quelque chose que l'application peut également reconnaître comme valide si c'est tout ce qu'elle doit continuer. S'il n'est pas reconnaissable, le processus de connexion ne saura pas non plus le bien du mal. L'attaquant peut utiliser la même approche.
@kjo: Eh bien, si vous souhaitez stocker en toute sécurité un bruit parfaitement aléatoire que vous n'utilisez jamais pour rien, cela pourrait être une approche réalisable. Lorsque l'attaquant fournit le mauvais mot de passe, il obtient le mauvais bruit et il n'en a aucune idée. C'est incassable - mais le casser ne vaut rien. Vous ne pouvez même pas l'utiliser pour sécuriser les données cryptées (qui semblent aléatoires) ou le bruit que vous avez réellement utilisé ou que vous prévoyez d'utiliser pour quelque chose (par exemple, comme un tampon ponctuel), car alors l'attaquant a un moyen de distinguer le mal de droite.
@kjo Jetez un œil à [cet ancien article sur le cryptogramme] (https://www.schneier.com/crypto-gram-9812.html#plaintext) pour savoir comment les attaques par force brute reconnaissent le succès.
@kjo Tout ce que l'attaquant a à faire est de répliquer ce que fait le serveur d'application pour déterminer si un mot de passe candidat est valide; ce processus doit évidemment être possible et ne pas dépendre de choses comme le fait que la sortie soit "reconnaissable". En règle générale, les étapes sont 1) créer le mot de passe candidat 2) ajouter le (s) sel (s) approprié (s) 3) hacher la chaîne résultante 4) vérifier la sortie de hachage par rapport au DB 5) répéter jusqu'à ce qu'elle corresponde.
Merci @AaronDufour: qui répond à la question dans mon commentaire. Je suppose qu'une manière de contrecarrer cette forme d'attaque serait que l'application effectue une opération que l'attaquant ne peut pas répliquer sur une machine différente (par exemple, l'application peut s'appuyer sur une clé spécifique à la machine intégrée au matériel).
@kjo qui peut encore être émulée à moins que la clé ne soit protégée. C'est l'idée derrière un hsm, mais de telles choses ne sont pas bon marché ni faciles à travailler.
Damon
2014-06-26 20:25:58 UTC
view on stackexchange narkive permalink

Pour les "attaques en ligne", ils le font, à des degrés divers et avec un succès variable. Habituellement, il s'agit simplement d'un désagrément pour l'utilisateur légitime et non d'un grand dissuasif pour les criminels.
Pour les attaques hors ligne, c'est impossible. Si quelqu'un a votre base de données de mots de passe, vous ne pouvez pas l'empêcher d'en faire quelque chose (bien que vous puissiez les retarder quelque peu).

Les téléphones portables fonctionnent de la manière exacte que vous décris. Après avoir entré votre code PIN de manière incorrecte au-delà d'un certain seuil (par exemple 3 tentatives), vous avez besoin du PUK pour débloquer l'appareil. Si cela m'arrive un jour, je serai très énervé, car j'ai jeté le morceau de papier où ce numéro à 10 chiffres est noté.

Mon routeur AVM vous bloquera pendant 5 secondes, doublant la durée de chaque échec de connexion. Ainsi, après 10 tentatives infructueuses, vous avez 42 minutes d'attente avant de pouvoir réessayer.

Un tel schéma n'est cependant que modérément intelligent. Bien qu'il soit peu probable que vous ayez une erreur de frappe 10 fois de suite, il est parfaitement possible que vous ne vous souveniez pas lequel des 10 mots de passe (mots de passe que vous utilisez rarement dans divers endroits, ou parmi les mots de passe que vous avez changé au fil du temps) est la bonne. En outre, cela permet une attaque par déni de service avec relativement peu de travail.
Bien sûr, l'attaquant doit également attendre entre les tentatives de connexion, mais il n'attend que 21 minutes, alors que vous devrez attendre 42 minutes (ou 6 heures pendant que vous attendez 12). De plus, si quelqu'un est simplement malveillant, attendre ne fait pas de mal, vous pouvez toujours régler un réveil sur 6 heures et faire une autre fausse connexion le soir. Pour l'utilisateur légitime, ce sera une journée complète d'attente, si cela fonctionne (et plus important encore, attendre fait mal si vous devez réellement faire quelque chose).
D'autres systèmes que j'ai vus avec certains sites Web sont encore moins intelligents. Dans un cas, il y a quelques années, j'ai été obligé de changer mon mot de passe pour déverrouiller mon compte parce que quelqu'un a fait quelques fausses connexions. Ce qui, bien sûr, n'a aucun sens puisque le mot de passe n'a manifestement pas été compromis (car ces tentatives de connexion ont échoué). Cette mesure de «sécurité» n'était qu'un désagrément très important pour le client, sans aucun avantage.

Dans la défense des développeurs, il n'est pas du tout facile (si possible) de trouver quelque chose qui fonctionne beaucoup mieux.

sixtyfootersdude
2014-06-26 21:15:15 UTC
view on stackexchange narkive permalink

Il y a un autre scénario qui serait difficile à détecter.

Regardons d'abord les scénarios contre lesquels il est facile de se défendre;

Facile: Défense contre une attaque par force brute sur un un seul utilisateur.

Les attaques par force brute sont également faciles à défendre si un seul utilisateur est la cible de l'attaque. Nous pouvons simplement verrouiller le compte de cet utilisateur. Cela peut ennuyer l'utilisateur, mais cela nous permet d'éviter que le système ne soit compromis.

  • connectez-vous à UserJoe
  • connectez-vous à UserJoe
  • connectez-vous à UserJoe
  • Connectez-vous à UserJoe
  • Connectez-vous à UserJoe
  • Verrouiller le compte de UserJoe

Facile : Défense contre les attaques par force brute à partir d'une seule adresse IP

Attaques par force brute faciles à détecter et à défendre, si toutes les requêtes proviennent de la même adresse IP.

Nous pouvons empêchez cette adresse IP de faire d'autres requêtes.

  • SomeIPAddress1 tente de se connecter
  • SomeIPAddress1 tente de se connecter
  • SomeIPAddress1 tente de se connecter
  • SomeIPAddress1 tente de se connecter
  • Empêcher SomeIPAddress1 de tenter de se connecter à l'avenir

Impossible (?): Défense contre une brute de botnet- forcer un nouvel utilisateur à chaque tentative.

Supposons que quelqu'un utilisant un botnet essaie de forcer brutalement votre système. Ils auront des adresses IP différentes, vous ne pourrez donc pas filtrer les connexions par adresse IP.

Supposons ensuite qu'ils essaient de se connecter à un utilisateur différent à chaque tentative.

Les requêtes pourraient donc ressemble à ceci:

  • SomeIPAddress1 tente de se connecter à UserJoe
  • SomeIPAddress2 tente de se connecter à UserAnne
  • SomeIPAddress3 tente de se connecter à UserMarc
  • SomeIPAddress4 essayant de se connecter à UserHanah
  • ...

Je ne vois aucun moyen de différencier les connexions légitimes des fausses connexions.

Pour la situation de botnet, n'est-il pas possible de changer la page de connexion / le gestionnaire juste assez pour que les bots existants ne puissent pas s'authentifier sans recevoir un nouveau code du "maître", ou, mieux encore, d'exiger un captcha?
@hexafraction Je pense que toutes les modifications que vous pouvez apporter à la connexion pourraient également être apportées aux bots. Cela peut vous faire gagner du temps, mais ce n'est pas vraiment un mécanisme de sécurité fiable. Bon point sur le captcha.
Même le captcha n'est pas la barrière qu'il pourrait sembler être. Mettez en place une ressource souhaitable sur Internet et placez-la derrière un captcha. Seulement, au lieu de générer un nouveau captcha, à chaque chargement de page, il vous suffit de saisir un défi captcha du site que vous souhaitez craquer. Lorsque votre propre visiteur humain vous donne la réponse, utilisez-la sur le site d'origine. Les ressources peuvent être des ROM de jeux, des fichiers audio MP3, de la pornographie ou tout autre contenu téléchargeable que les gens désirent. On pourrait même, avec un botnet de machines compromises, faire un captcha une fois par heure au hasard sur le bureau. Captcha n'est pas la réponse finale.
Je n'aime pas la solution captcha. Peut-être simplement ajouter un délai à la validation du compte. Augmentez le délai avec le nombre d'échecs de connexion. Vérifiez également vos comptes d'utilisateurs pour des mots de passe très simples. Verrouillez ces comptes et envoyez un e-mail de changement de mot de passe.
Dans le cas du botnet, en supposant que vous ayez quelque chose comme fail2ban en cours d'exécution et que chaque bot n'obtienne que deux essais avant d'être verrouillé pendant une heure, vous mettez toujours en place une défense décente ...
@Shadur - Cela représente probablement deux essais ** par adresse IP ** par heure, ce qui pourrait encore représenter beaucoup d'essais.
Mais toujours environ un ordre de grandeur moins d'essais que sans fail2ban. Peut-être assez pour faire la différence.
Notez que si vous obtenez de nombreuses tentatives de connexion infructueuses, même à partir de nombreuses adresses IP variables, des tentatives qui ne finissent pas par être valides, vous pouvez les détecter et bloquer toutes les connexions pendant un certain temps. Selon le type de sites Web que vous avez, cela pourrait être plus sûr que de laisser la porte ouverte ...
Phil Perry
2014-06-26 21:02:21 UTC
view on stackexchange narkive permalink

Ce sera toujours un exercice d'équilibrage du temps qu'il faudra attendre après une tentative de connexion incorrecte. Il n'est pas déraisonnable de continuer à augmenter le temps d'attente après chaque tentative (et éventuellement de verrouiller d'autres tentatives jusqu'à une sorte de réinitialisation), mais cela doit être lié à l'adresse IP sur laquelle la tentative se déroule, de sorte que l'utilisateur légitime ne le fasse pas. t être également mis en lock-out (victime parce que quelqu'un tente de pénétrer dans son compte) Cependant, une attaque distribuée (à partir de nombreuses adresses IP) peut charger le système au point de devenir une simple attaque DDoS.

Si quelqu'un est déterminé à essayer tout un tas de mots de passe (pas nécessairement tous les possibles , juste les plus courants / probables) et a un troupeau de machines zombifiées pour le faire , soit ils finiront par réussir, soit ils mettront le système à genoux. N'oubliez pas qu'imposer un temps d'attente (refuser les demandes de connexion) ou refuser une adresse IP utilise également des ressources. Et si vous avez tellement de mots de passe que vous ne vous souvenez plus lequel utiliser, vous avez un problème avec votre méthodologie si vous devez les parcourir tous!

Un défi de "question de sécurité" (en gros, un mot de passe alternatif) après autant de tentatives infructueuses est possible, tout comme l'envoi d'un mot de passe à usage unique (réinitialisation) à une adresse e-mail enregistrée (que ce soit automatiquement ou une demande de «mot de passe oublié»), de même qu'un verrouillage sur cette adresse IP pendant un temps donné ou jusqu'à ce qu'un administrateur soit invité à le déverrouiller. J'ai vu toutes ces méthodes utilisées.

Si l'attaquant possède des informations privilégiées, à savoir le fichier de mot de passe haché ou chiffré, il peut effectuer l'essentiel de son travail hors ligne et se connecter une seule fois (après avoir déterminé le mot de passe à utiliser). Les mots de passe doivent toujours être stockés sous forme de hachages (chiffrement unidirectionnel), et jamais en texte brut ou même sous une forme chiffrée réversible. Les hachages sont difficiles (mais pas impossibles) à récupérer le mot de passe en texte brut, surtout s'ils sont salés (de sorte que le hachage n'est pas le même pour deux utilisateurs différents qui ont choisi "secret" pour leur mot de passe).

PiTheNumber
2014-06-26 19:18:57 UTC
view on stackexchange narkive permalink

Parce que le client ne paie pas pour la sécurité.

Vous devez créer une table de base de données. Collectez les adresses IP des échecs de connexion. Nettoyez régulièrement cette table. Créez une autre table avec des adresses IP bloquées et nettoyez-la également. Vous voyez que cela demande un certain effort et que les clients n'aiment pas payer un supplément juste pour la sécurité.

En tant que développeur, vous devriez utiliser des frameworks qui prendront en charge ces problèmes. Vous voudrez peut-être aussi jeter un œil à fail2ban.

Je ne pense toujours pas qu'il y ait de défense contre le scénario que je décris dans ma réponse: http://security.stackexchange.com/a/61936/874


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