Existe-t-il une méthode standard pour prouver la sécurité des mots de passe aux non-mathématiciens?

16

Mon client possède un serveur qui est soumis à des tentatives de connexion par force brute à partir d'un botnet. En raison des aléas du serveur et du client du client, nous ne pouvons pas facilement bloquer les tentatives via un pare-feu, un changement de port ou un changement de nom de compte de connexion.

La décision a été prise de le laisser ouvert aux attaques, mais de trouver une méthode pour sécuriser le mot de passe. La direction et certains autres consultants ont déterminé que la meilleure chose à faire est d'installer un logiciel de rotation de mot de passe pour faire pivoter le mot de passe toutes les dix minutes et fournir le nouveau mot de passe aux utilisateurs qui doivent se connecter.

Les tentatives de force brute se produisent deux fois par seconde.

Je dois démontrer que l'implémentation d'un mot de passe fort avec 12-15 caractères est une solution plus simple et gratuite. Je sais comment le prouver avec les maths, mais j'écrirais juste quelque chose comme "il y a x beaucoup de permutations possibles de notre mot de passe, et l'attaquant ne peut essayer que n tentatives par jour, donc nous nous attendrions à ce qu'il aille x / 2 jours en moyenne avant de deviner notre mot de passe. " Existe-t-il une "preuve" plus standard de cela?

Porcs
la source

Réponses:

14

L'utilisation de fail2ban avec iptables est un excellent moyen.

Voici les maths pour vous:

L'alphabet mixte majuscule et minuscule et les symboles communs, de 8 caractères, vous donnent 2,9 quadrillions de combinaisons et avec 10 000 tentatives par seconde, cela prendra 9 488 ans. C'est le maximum bien sûr - attendez-vous à ce que votre mot de passe soit déchiffré dans 4000 ans. 1000 ans si vous ne vous sentez pas chanceux.

Comme vous pouvez le voir, vous ne devriez pas avoir de problèmes si vous utilisez un mot de passe à 15 caractères comme:

dJ&3${bs2ujc"qX
Steven
la source
Comment fail2ban aiderait-il contre un botnet?
innaM
2
le seul problème que vous aurez, c'est que personne ne peut se souvenir de leurs mots de passe ..
Jeff Atwood
C'est un lien vraiment intéressant, mais j'ai remarqué (au bas de la page) que leurs temps d'attaque sont basés autour du Pentium 100! Peut-être un peu dépassé maintenant, mais toujours une bonne lecture.
Coops
8

En plus de fail2ban,

Si vous utilisez un système UNIX moderne, vous pouvez généralement modifier le temps de veille de la saisie du mauvais mot de passe jusqu'à 5 secondes, ce qui ralentit la vitesse d'attaque de 2000%. [Solaris 10 l'a dans / etc / default / login, recherchez SLEEPTIME] Ce qui, en utilisant les mêmes tolérances, signifierait que vous pourriez faire pivoter le mot de passe toutes les 3 heures 20 minutes.

De plus, les tentatives de mot de passe avant le verrouillage seraient une option viable, mais je soupçonne que ce n'est pas pour vous car vous avez plusieurs utilisateurs partageant un compte et que vous ne voulez pas qu'il soit verrouillé tout le temps.

Exiger un mot de passe de 12 à 15 caractères aide, mais si vous êtes continuellement attaqué, une autre solution est probablement meilleure. Je ne sais pas quelle est la tolérance budgétaire de votre entreprise à ce sujet, mais les cartes clés RSA pour tous ceux qui doivent se connecter à ce compte le résoudraient également. L'authentification à deux facteurs repousse la probabilité dans le temps de calcul quantique.

L'approche par force brute qui dure assez longtemps pour que vous puissiez poster sur ce forum est assez surprenante. De manière générale, il est assez bas et est au mieux un remplisseur de journaux alors qu'une véritable attaque est en cours.

user5605
la source
6

Que diriez-vous d'un appel à l'autorité? Vous pouvez vous référer aux directives techniques d'implémentation de la sécurité du DoD (iase.disa.mil/stigs/stig) et dire "si c'est assez bon pour le ministère de la Défense, c'est assez bon pour nous"

Brien
la source
5

Quelque chose à considérer: si vous avez un mot de passe qui ne change pas et que les attaques par force brute testent un univers de mots de passe qui inclut le vôtre, l'attaque par force brute est garantie de frapper finalement et vous resterez vulnérable après cela.

La "chance" qu'un choix aléatoire atteindra votre mot de passe peut être calculée, comme vous l'avez suggéré, mais cela peut ne pas raconter toute l'histoire.

Si vous regardez les tentatives de force brute, par exemple, et voyez que le mot de passe le plus long qu'ils essayent est de 10 caractères, choisir quoi que ce soit à 12 vous assurera de ne jamais être touché.

Soyez très prudent lorsque vous essayez d'appliquer des statistiques à un cas particulier; ils prédisent uniquement le comportement global avec un grand nombre d'échantillons.

Cela mis à part, si les mathématiques ne convainquent pas (ou ne peuvent pas) convaincre quelqu'un, essayez de trouver quelque chose qui a à peu près les mêmes chances de se produire mais qui est familier, comme des loteries ou des accidents de voiture ou frappé par la foudre. Si vous pouvez dire que "la chance que quelqu'un frappe ce mot de passe équivaut à peu près à gagner à la loterie six semaines consécutives", cela peut lui donner une meilleure idée.

piCookie
la source
3
Pourquoi ne pas choisir un mot de passe que l'attaquant a déjà essayé? Je rigole.
innaM
4

Une chose qui n'a pas été prise en compte est le nom d'utilisateur que le botnet utilise pour Bruteforce. Dans tous les cas, j'ai vu que les forces brutes concernaient des variantes d'administration et de racine, et dans un rare cas, les noms d'utilisateurs ont été supprimés du site Web du corp.

Je modifierais également les restrictions de connexion interactive afin que votre compte root soit désactivé (préféré) ou limité à votre sous-réseau local ou à une plage d'adresses similaire.

Preflightsiren
la source
2

Deux fois par seconde n'est pas mauvais. Nous avions l'habitude de voir des milliers de tentatives par minute, avant d'implémenter fail2ban , qui verrouillera une adresse IP particulière du réseau pendant une durée définie après tant de tentatives infructueuses (toutes configurables).

Cela a très bien fonctionné pour nous.

Brent
la source
2

En fait, vous pouvez effectuer une analyse sélective contre les attaques ssh par force brute à l'aide d'iptables, si cela fonctionne pour vous.

Ces deux chaînes:

iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -m recent --set --name sshscans 
iptables -A INPUT -m recent --rcheck --seconds 60 --hitcount 5 --name sshscans --rsource -j DROP 

bloquera l'accès à toute personne qui tente de se connecter à SSH plus de 5 fois dans un intervalle de 60 secondes. Vous pouvez modifier le nombre "--hitcount" si vous souhaitez qu'un nombre supérieur à 5 par seconde soit autorisé.

palmer
la source
2

Je suis d'accord que changer le mot de passe toutes les 10 minutes semble un peu excessif. À ce stade, le problème est de savoir comment transmettre en toute sécurité le nouveau mot de passe et garder les systèmes synchronisés entre eux.

Cet article contient des statistiques intéressantes sur les vitesses de fissuration:

http://www.lockdown.co.uk/?pg=combi

http://en.wikipedia.org/wiki/Password_cracking

Peter
la source
2

Il est surprenant de voir combien de personnes ne comprennent pas les courbes exponentielles, mais tout le monde connaît la différence entre 10, 100 et 1000, ce qui pourrait être un bon endroit pour commencer à faire des comparaisons.

Une autre tactique pourrait être de montrer aux gens combien de temps il faut pour forcer un mot de passe à 6 caractères. Si vous avez des connaissances en programmation, vous pouvez créer un outil rapide qui le fait.

Maximus Minimus
la source
2

Vous pouvez également leur montrer à quel point les tables arc-en-ciel sont facilement disponibles:

http://project-rainbowcrack.com/table.htm

Riches
la source
Ce n'est utile que s'ils obtiennent le hachage du mot de passe, et avec un salage approprié, la menace peut être atténuée.
skitzot33
2

Cela peut être un peu hors sujet, mais j'utilise denyhosts et cela réduit considérablement les tentatives de force brute sur mes boîtiers Linux.

skitzot33
la source