Pourquoi ne sels attaques par dictionnaire "impossible"?

Mise à jour: Veuillez noter que je ne suis pas demande ce qu'est un sel est, ce qu'est un arc-en-ciel de la table est, ce qu'une attaque par dictionnaire est, ou quel est le but d'un sel. Je suis interrogation: Si vous connaissez les utilisateurs de sel et de hachage, n'est-il pas tout à fait facile de calculer leur mot de passe?

Je comprends le processus, et de mettre en œuvre moi-même dans certains de mes projets.

s =  random salt
storedPassword = sha1(password + s)

Dans la base de données à stocker:

username | hashed_password | salt

Chaque mise en œuvre de salage j'ai vu, ajoute le sel, soit à la fin du mot de passe, ou le début:

hashed_Password = sha1(s + password )
hashed_Password = sha1(password + s)

Donc, une attaque de dictionnaire à partir d'un hacker qui vaut son sel (ha ha) serait tout simplement d'exécution de chaque mot-clé contre la stockées sels dans la commune de combinaisons énumérées ci-dessus.

Sûrement la mise en œuvre décrit ci-dessus ajoute simplement une autre étape pour le pirate, sans vraiment résoudre le problème sous-jacent? Quelles sont les alternatives à l'étape autour de ce problème ou suis-je à la mauvaise compréhension du problème?

La seule chose que je peux penser à faire est d'avoir un secret de fusion l'algorithme que lacets, le sel et le mot de passe ensemble dans un motif aléatoire, ou ajoute d'autres champs d'utilisateur pour le processus de hachage sens le pirate devrait avoir accès à la base de données ET le code de la dentelle pour une attaque par dictionnaire s'avérer fructueuse. (Mise à jour, comme l'a souligné dans les commentaires, il est préférable d'assumer le pirate a accès à toutes vos informations de sorte que ce n'est probablement pas le meilleur choix).

Permettez-moi de donner un exemple de la façon dont je propose un hacker aurait pirater un utilisateur de base de données avec une liste de mots de passe et les tables de hachage:

Données de notre piraté la base de données:

RawPassword (not stored)  |  Hashed   |     Salt
--------------------------------------------------------
letmein                       WEFLS...       WEFOJFOFO...

Commune dictionnaire de mots de passe:

   Common Password
   --------------
   letmein
   12345
   ...

Pour chaque enregistrement de l'utilisateur, de la boucle de la commune de hachage des mots de passe et eux:

for each user in hacked_DB

    salt = users_salt
    hashed_pw = users_hashed_password

    for each common_password

        testhash = sha1(common_password + salt)
        if testhash = hashed_pw then
           //Match!  Users password = common_password
           //Lets visit the webpage and login now.
        end if

    next

next

J'espère que cela illustre mon point beaucoup mieux.

Donné de 10 000 mots de passe communs, et de 10 000 enregistrements d'utilisateur, nous aurions besoin de calculer 100 000 000 d'hachages de découvrir de nombreux mots de passe des utilisateurs que possible. Il peut prendre quelques heures, mais ce n'est pas vraiment un problème.

Mise à jour sur la Théorie de la Fissuration

Nous allons supposer que nous sommes corrompus hébergeur, qui a accès à une base de données de SHA1 les hachages et les sels, le long de avec votre algorithme pour les mélanger. La base de données de 10 000 enregistrements d'utilisateur.

Ce site prétend être capable de calculer 2,300,000,000 SHA1 hachages par seconde en utilisant le GPU. (Dans le monde réel de la situation sera probablement plus lent, mais pour l'instant, nous allons utiliser celle qui est indiquée à la figure).

(((95^4)/2300000000)/2)*10000 = 177
secondes

Donné une gamme complète de 95 caractères ASCII imprimables, avec une longueur maximale de 4 caractères, divisé par le taux de calcul (variable), divisé par 2 (en supposant que le temps moyen de découvrir le mot de passe en moyenne besoin de 50% de permutations) pour 10 000 utilisateurs il faudrait 177 secondes pour travailler tous les utilisateurs des mots de passe, où la longueur est <= 4.

Nous allons ajuster un peu de réalisme.

(((36^7)/1000000000)/2)*10000 = 2 jours

En supposant que le non respect de la casse, avec une longueur de mot de passe <= 7, seuls les caractères alphanumériques, il faudra 4 jours pour résoudre de 10 000 enregistrements d'utilisateur, et j'ai réduit de moitié la vitesse de l'algorithme afin de refléter les frais généraux et non idéal circonstance.

Il est important de reconnaître que ce linéaire d'une attaque de force brute, tous les calculs sont indépendants l'un de l'autre, donc c'est parfait tâche pour plusieurs systèmes à résoudre. (C'est à dire facile à mettre en place 2 ordinateurs exécutant une attaque à partir de différentes fins qui serait la moitié de la cours d'exécution en temps).

Compte tenu de l'affaire de manière récursive le hachage d'un mot de passe 1000 fois pour rendre cette tâche plus gourmand en ressources:

(((36^7) /1 000 000 000) /2) * 1000
secondes = 10.8839117 heures

Ce qui représente une longueur maximale de 7 caractères alpha-numériques, à moins de la moitié de la vitesse d'exécution de cité figure pour un utilisateur.

De façon récursive de hachage 1000 fois bloque efficacement une couverture de l'attaque, mais de manière ciblée les attaques sur les données de l'utilisateur sont toujours vulnérables.

  • Le point entier dans le salage est pour vous empêcher d'être en mesure de regarder le hachage de mot de passe et de voir que plusieurs utilisateurs ont le même hash (et donc le même mot de passe). Sans salage vous pouvez simplement utiliser l'algorithme de hachage et de générer tous les possible de hachage et de procéder à une brute de recherche pour ce symbole. Puisque l'algorithme ne change jamais, il le rend prévisible pour les attaquants, saler juste rend beaucoup plus difficile.
  • ici, il est discuté en détail : stackoverflow.com/questions/420843/...
  • Merci @sera, je suppose que le point que je suis en train de faire, c'est qu'il est présenté comme un très sécurisée, alors qu'en réalité il ne l'est pas, il a juste obscurcit les données assez pour faire les pirates de l'emploi un peu plus irritant
  • Oui, mais si vous utilisez un assez compliqué algorithme de hachage avec un bon pseudo-aléatoire de sel alors vous pouvez pousser la complexité de la résolution du problème dans les royaumes de l'impossibilité physique sur toute moderne/l'avenir matériel. 2^128 est un très gros chiffre!
  • Si un pirate a accès à le sel + le hachage de mot de passe, il leur suffit d'exécuter tout le sel + dictionnaire des combinaisons de mots de passe, pour n dictionnaire des mots de passe, vous devez effectuer n hachage de calculs par compte d'utilisateur, beaucoup plus gourmand en ressources, mais parfaitement facile pour un ordinateur portable pour effectuer plus de quelques heures. Je ne sais pas si ma question est assez claire?
  • Parce que les craquelins sont comme des limaces, et le sel assèche les muqueuses de la peau, et les tue.
  • J'aime assez salés biscuits. Salé limaces, pas tellement.
  • dans votre exemple de l'attaque. Si il n'y a pas de sel, puis l'attaquant peut faire "pour chaque mot de passe commun, hacher le mot de passe. - Il correspondre à un ou plusieurs utilisateurs? Oui, j'ai son mot de passe" - l'attaquant est capable de s'attaquer à tous les mots de passe "en parallèle", sans coût supplémentaire.
  • Gullen - vous avez seulement la moitié de l'image. Sans sel, un attaquant ne serait pas utiliser la méthode que vous le démontrer dans "mise à Jour 2". Il suffit de faire une recherche dans une table et obtenir le mot de passe en O(1) O(log n) temps (n étant le nombre de candidats pour les mots de passe). Le sel est ce qui l'en empêche et l'oblige à recourir à l'O(n) approche de vous démontrer. Une autre technique (clé-renforcement) peut provoquer chaque tentative dans votre boucle de prendre une seconde, ce qui signifie qu'il va prendre 3 ans pour effectuer ces tests... et avec seulement 10k mots de passe, vous êtes susceptible de se fissurer à zéro les mots de passe en ce moment.
  • Je ne savais pas que vous étiez en supposant que le sel avait été compromis. Alors que, techniquement, vous avez raison, le vrai problème, c'est que le hacker a compromis l'ensemble de la base de données avant de commencer. C'est un problème beaucoup plus vaste que le fait qu'il peut casser des mots de passe courants dans les 3 jours 😉 le Salage n'est pas destinée à prévenir de quoi vous parlez, mais plutôt pour empêcher les pirates d'accéder à tous les mot de passe de votre base de données en une seule fois. Il est - comme toutes les formes de chiffrement simplement une méthode pour gêner l'attaquant
  • clé stengthening est un autre bon point. Faire de l'algorithme de hachage coûteuse en termes de calcul et de vous faire de nouveau craquage de moins en moins probable.
  • Merci, quand dans le monde réel a une liste de mots de passe à été piraté sans avoir accès aux valeurs du sel? Il serait peut-être plus commun que j'assume, je me demandais.
  • Merci également erickson, voulez-vous dire ressasser le résultat le dire 100 fois pour le rendre gourmand en ressources? Ou à l'aide d'un plus lourd algorithme de hachage? Je pouvais voir qu'elle fonctionne bien, mais pas l'article ou le guide que j'ai lu en ligne n'a jamais suggéré que.
  • Gullen - je veux dire re-hachage le résultat de 2000 temps (que vous avez à considérer qu'un attaquant va utiliser quelque chose de rapide, pas de PHP), de sorte qu'il faut une bonne fraction de seconde pour calculer la valeur de hachage d'un mot de passe unique. Cela se retrouve dans la norme de dérivation de clé algorithmes PBKDF1 et PBKDF2, de PKCS #5, qui font de grands mot de passe de l'obscurcissement des algorithmes (la "clé dérivée" est le "hash"). Beaucoup d'utilisateurs sur référez-vous à cet article parce que c'était une réponse à Jeff Atwood.
  • Généralement, supposons toujours que votre code et de votre base de données peut être la connaissance du public. Cela signifie que le fait d'avoir un moyen secret de mélanger le sel avec le mot de passe, comme vous le mentionnez, est une mauvaise idée, dans l'essentiel étant de la sécurité par l'obscurité. Non pas que j'ai de vous voir de la publicité pour elle, mais je voudrais juste mentionner pour obtenir des éclaircissements.
  • BTW, bien sûr, vous assumez l'attaquant a tout. Supposons que l'attaquant est un corrompu de l'hébergement des employés de la société qui sous-évaluées sur la table utilisateur sur votre myprettypony.com fansite de sorte qu'il peut récupérer des mots de passe et de voir si elles fonctionnent sur les gens du citibank.com comptes. Avec un mot de passe système, il sera impossible pour ce type de récupérer tous les mots de passe.
  • Merci Boris, mais beaucoup de la sécurité est la sécurité par l'obscurité n'est-ce pas? C'est essentiellement ce que un hash est?
  • merci pour les précisions, vous pouvez le mettre dans une réponse, c'est exactement ce que je recherchais.
  • excellent article, merci pour le lien
  • Voir aussi: stackoverflow.com/questions/213380/... et stackoverflow.com/questions/1645161/... et stackoverflow.com/questions/536584/...
  • Concernant la sécurité par l'obscurité: Non, il n'est pas. La sécurité Par l'Obscurité est à l'aide d'une faiblesse de la méthode et en supposant que vous pouvez empêcher les gens d'apprendre ce que cette methode est. Le point de sel est de conduire le coût moyen (dans le temps, la puissance de traitement, de l'espace disque, factures d'électricité, peu importe) de l'attaque supérieur à la valeur attendue à être gagné par la réussite ou de pousser la durée de réussite assez loin dans l'avenir qu'il n'a pas d'importance (par exemple, au-delà de la prochaine obligatoire de changement de mot de passe).
  • merci mais j'étais sous l'impression de la définition de la sécurité par l'obscurité ne permet pas de couvrir la "faiblesse" de la solution? C'est à dire, ce n'est pas, par définition, necesserially faible. Votre remarque au sujet de la signification d'un secret de la méthode est correcte bien que, de mon point est, par exemple, est la clé publique de chiffrement de la STO parce que vous la méthode est de combiner un "secret key"?
  • J'ai mis à jour la question avec quelques chiffres sur la fissure fois pour divers scénarios, jusqu'à présent, j'ai appris que récursive de hachage protège sur couverture de fissures, et j'espère que j'ai prouvé que, mais la question qui se pose maintenant est de savoir comment pouvons-nous protéger contre les attaques ciblées? Ce qui revient à l'utilisateur, et si vous avez besoin d'un 9 caractère de mot de passe avec un char spécial, et la sensibilité de cas vous serez à la recherche à (((95^9) / 1000000000) / 2) * 1000 secondes en années = 10 000 ans à se fissurer.
  • Désolé, mais cette question n'est pas un doublon, donc j'ai voté pour la réouverture. Beaucoup de réponses semblent décrire ce qu'est un sel est, pourquoi il est là, qui ne traite pas de la question. Cette question est plus précis que ça.
  • De Plus, nous sommes la génération discussion intéressante donc ce serait bien de le garder ouvert!
  • "Évitez de poser des questions [...] nécessitent de longues discussions." -- La FAQ

InformationsquelleAutor Tom Gullen | 2010-08-25