La Non-aléatoire de sel pour le hachage de mots de passe
Mise à JOUR: j'ai récemment appris de cette question que dans l'ensemble de la discussion ci-dessous, je (et je suis sûr que les autres l'ont fait aussi) était un peu confus: Ce que je l'appel, un arc-en-ciel de la table, s'appelle en fait une table de hachage. Rainbow tables sont plus complexes créatures, et sont en fait une variante de Hellman Chaînes de Hachage. Mais je crois que la réponse est toujours la même (car il ne descendit pas à la cryptanalyse), quelques éléments de la discussion peut-être un peu biaisé.
La question: "Ce sont des rainbow tables et comment sont-ils utilisés?"
En général, je recommande toujours à l'aide d'un chiffrement puissant valeur aléatoire comme le sel, pour être utilisé avec les fonctions de hachage (par exemple, pour les mots de passe), comme la protection contre l'arc-en-ciel de la Table des attaques.
Mais est-il réellement du point de vue cryptographique nécessaire pour le sel aléatoire? Serait une valeur unique (unique par utilisateur, par exemple userId) suffit à cet égard? Il serait, en effet, de prévenir à l'aide d'un simple arc-en-ciel de la Table pour faire craquer tous (ou la plupart) des mots de passe dans le système...
Mais le manque d'entropie vraiment affaiblir la robustesse cryptographique des fonctions de hachage?
Remarque, je ne demande pas au sujet de pourquoi utiliser du sel, comment la protéger (il n'a pas besoin de l'être), à l'aide d'une seule constante de hachage (ne), ou ce genre de fonction de hachage à utiliser.
Simplement de savoir si le sel besoins de l'entropie ou pas.
Merci à tous pour les réponses, mais j'aimerais me concentrer sur les domaines que je suis (un peu) moins familiers avec. Principalement des implications pour la cryptanalyse - j'apprécierais plus si quelqu'un a des commentaires à partir de la crypto-mathématiques PoV.
Aussi, si il y a d'autres vecteurs qui n'avait pas été pris en compte, c'est la grande entrée (voir @Dave Sherohman point sur plusieurs systèmes).
Au-delà, si vous avez une théorie, une idée ou une meilleure pratique - s'il vous plaît revenir ce soit avec la preuve, le scénario d'attaque, ou de preuves empiriques. Ou même les considérations valables pour les contreparties acceptables... je suis familier avec les Meilleures Pratiques (capitale de capital B P) sur le sujet, je tiens à prouver que la valeur de cette offre dans la réalité.
EDIT: Quelques bonnes réponses ici, mais je pense que @Dave dit, il s'agit de Rainbow Tables pour le commun des noms d'utilisateur... et possible des noms peu communs aussi. Cependant, que faire si mes identifiants sont uniques au monde? Pas nécessairement unique de mon système, mais par chaque utilisateur - par exemple, adresse mail.
Il n'y aurait aucune incitation à construire un RT pour un seul utilisateur (comme @Dave a souligné, le sel n'est pas secrète), et ce serait encore l'empêcher de clustering. Seul problème serait que je puisse avoir la même adresse email et le mot de passe sur un autre site mais le sel n'est pas d'empêcher que de toute façon.
Donc, il revient à la cryptanalyse EST l'entropie nécessaire, ou pas? (Ma pensée est qu'il n'est pas nécessaire à partir d'une cryptanalyse point de vue, mais il est d'autres raisons pratiques.)
- Je dois dire que je suis confus par beaucoup de réponses ci-dessous. Le point principal de l'utilisation de sel est tout simplement pour éviter arc-en-ciel tableau attaque, donc quelque chose d'unique à l'utilisateur, comme elle l'forces de l'attaquant de recréer un arc-en-ciel de la table pour chaque sel. mon 2c.
- Si le sel est nécessaire pour, par exemple. site, vous avez souvent des id dans l'url. Si le pirate sait (et nous supposons qu'il n') que le mot de passe de sel est userid+nom d'utilisateur, il est assez facile de modifier l'attaque pour éviter le sel de la valeur.
- le sel est destiné à prévenir RT attaques et de différencier les mêmes mots de passe pour différents utilisateurs. C'est un fait, même avec des noms d'utilisateur.
- C'est vrai. Mais si je sais que mon hachage pour mon laissez-passer, et je sais que le sel est mon nom d'utilisateur, puis je peux facilement créer haché passer de la valeur pour n'importe quel mot du dictionnaire et de le comparer à quelqu'un d'autre passe de hachage. C'est pourquoi le temps est mieux que nom d'utilisateur.
- ( pas de formation ) - Traditionnellement, en essayant de mieux ce qui a été réalisé est sujette aux erreurs, au minimum peut détourner l'attention des autres questions. De ce que je vois, la seule question est de s'assurer que le sel est d'une longueur suffisante pour faire bouger les choses, alors il est à peu près algorithme de force à partir de là, non?
- Voir aussi: stackoverflow.com/questions/1645161/...
- Viens de trouver un article sur le PHP Security Consortium site web que dans son exemple utilise un md5 haché nombre aléatoire comme le sel phpsec.org/articles/2005/password-hashing.html
Vous devez vous connecter pour publier un commentaire.
Sel est traditionnellement stockées comme préfixe pour le hachage de mot de passe. Cela a déjà fait savoir à tout utilisateur malveillant d'accéder à la hash du mot de passe. En utilisant le nom d'utilisateur comme le sel ou non n'a pas d'incidence sur la connaissance et, par conséquent, elle n'aurait aucun effet sur le système unique de sécurité.
Cependant, en utilisant le nom d'utilisateur ou de toute autre contrôlée par l'utilisateur de la valeur du sel, permettrait de réduire d'un système de sécurité, un utilisateur qui a le même nom d'utilisateur et mot de passe sur plusieurs systèmes qui utilisent le même mot de passe algorithme de hachage allait se retrouver avec le même hash du mot de passe sur chacun de ces systèmes. Je ne la considère pas comme une importante responsabilité, parce que moi, en tant qu'attaquant, serait d'essayer les mots de passe d'un compte cible est connu pour avoir utilisé sur d'autres systèmes avant d'essayer de tout autre moyen de compromettre le compte. Identique hachages serait seulement de me dire à l'avance que le mot de passe de travail, ils ne feraient pas l'attaque réelle, tout est plus facile. (Notez, cependant, qu'une comparaison rapide des bases de données de compte serait de fournir une liste de priorité plus élevée des objectifs, car il faudrait me dire qui est et qui n'est pas la réutilisation de mots de passe.)
Le plus grand danger de cette idée est que les noms d'utilisateur sont généralement réutilisés - juste au sujet de n'importe quel site de votre visite permettra de disposer d'un compte utilisateur nommé "Dave", par exemple, et "admin" ou "root" sont encore plus fréquents qui en ferait la construction de tables arc-en-ciblage des utilisateurs avec ces noms communs beaucoup plus facile et plus efficace.
Deux de ces failles pouvaient être traités efficacement par l'ajout d'un second sel de la valeur (fixe et cachés ou exposés comme la norme de sel) pour le mot de passe avant le hachage, mais, à ce stade, vous pourriez aussi bien être en utilisant la norme entropique de sel, de toute façon, au lieu de travailler le nom d'utilisateur en elle.
Modifiées afin d'Ajouter: beaucoup de gens parlent de l'entropie et si l'entropie de sel est important. C'est bien, mais pas pour la raison que la plupart des commentaires sur l'air de penser.
La pensée générale semble être que l'entropie est important de sorte que le sel sera difficile pour un attaquant de deviner. Ceci est incorrect et, en fait, complètement hors de propos. Comme cela a été souligné à quelques reprises par des personnes différentes, des attaques qui sera affectée par le sel ne peut être fait par quelqu'un avec le mot de passe de la base de données et quelqu'un avec le mot de passe de la base de données peut-il suffit de regarder pour voir ce que chaque compte est le sel. Si c'est de deviner ou pas n'a pas d'importance quand vous pouvez trivialement le regarder.
La raison que l'entropie est important, c'est d'éviter le regroupement des valeurs du sel. Si le sel est basé sur le nom d'utilisateur et de vous savez que la plupart des systèmes ont un compte nommé soit "root" ou "admin", puis vous pouvez faire un arc-en-ciel de la table pour ces deux sels et il va craquer la plupart des systèmes. Si, d'autre part, un échantillon aléatoire de 16 bits, le sel est utilisé et les valeurs aléatoires ont à peu près la même distribution, alors vous avez besoin d'un arc-en-ciel de table pour tous les 2^16 sels possibles.
Il n'est pas sur la prévention de l'attaquant de savoir ce qu'est un compte individuel de sel, c'est de ne pas leur donner la grosse cible d'un seul sel qui sera utilisé sur une part substantielle des cibles potentielles.
passhash = md5("urhu2389udfcbdvalk" + UserPassword)
serait-ce sécurisé?À l'aide d'un haut-entropie sel est absolument nécessaire pour stocker les mots de passe de manière sécurisée.
Prendre mon nom d'utilisateur " gs " et l'ajouter à mon mot de passe 'Monmotdepasse' donne gsMyPassword. Ceci est facilement brisée à l'aide d'un arc-en-ciel de la table, parce que si le nom d'utilisateur n'a pas obtenu suffisamment d'entropie, il se pourrait que cette valeur est déjà stocké dans l'arc-en-ciel de la table, surtout si le nom d'utilisateur est court.
Un autre problème sont les attaques où l'on sait qu'un utilisateur participe à deux ou plus de services. Il ya beaucoup de commune, les noms d'utilisateur, probablement les plus importants sont admin et root. Si quelqu'un créé un arc-en-ciel de la table qui ont des sels avec les plus communs des noms d'utilisateur, il pourrait utiliser pour compromettre des comptes.
Ils ont un 12 bits de sel. 12 bits 4096 combinaisons différentes. Ce n'était pas assez sûr, parce que beaucoup d'informations peuvent être facilement stockées aujourd'hui. La même chose s'applique pour les 4096 plus utilisé des noms d'utilisateurs. Il est probable que quelques-uns de vos utilisateurs seront en choisissant un nom d'utilisateur qui appartient à la plupart des noms d'utilisateur.
J'ai trouvé cette vérificateur de mot de passe qui fonctionne à l'entropie de votre mot de passe. D'avoir moins d'entropie dans les mots de passe (comme en utilisant des noms d'utilisateurs), il est beaucoup plus facile pour rainbowtables comme ils essaient de couvrir au moins tous les mots de passe avec une faible entropie, parce qu'ils sont plus susceptibles de se produire.
Il est vrai que le nom d'utilisateur peut être problématique, car les gens peuvent partager les noms d'utilisateur entre les différents site web. Mais il devrait être plutôt un problème si les utilisateurs avaient un nom différent sur chaque site. Alors pourquoi ne pas tout à fait unique sur chaque site. Hacher le mot de passe un peu comme ce
hashfunction("www.yourpage.com/"+username+"/"+mot de passe)
Ce qui devrait résoudre le problème. Je ne suis pas un maître de la cryptanalyse, mais je doute que le fait que nous n'utilisons pas de haute entropie rendrait le hachage affaiblie.
J'aime utiliser les deux: une haute entropie aléatoire du nombre d'enregistrements de sel, en plus de l'IDENTIFIANT unique de l'enregistrement lui-même.
Si ce n'est pas ajouter beaucoup à la sécurité contre les attaques par dictionnaire, etc., il n'supprimer la frange cas où quelqu'un copie de leur sel et pommes de terre à un autre enregistrement avec l'intention de remplacer le mot de passe avec leur propre.
(Il est vrai qu'il est difficile de penser à une circonstance où cela s'applique, mais je ne vois pas de mal à ceintures et bretelles quand il s'agit de la sécurité.)
Si le sel est connu ou facilement deviner, vous n'avez pas augmenté la difficulté d'une attaque par dictionnaire. Il peut même être possible de créer une modification de l'arc-en-ciel de la table qui prend une "constante" de sel en compte.
Unique à l'aide de sels augmente la difficulté de la masse des attaques de dictionnaire.
Avoir unique, à fort niveau de chiffrement le sel de la valeur serait l'idéal.
Je dirais que tant que le sel est différent pour chaque mot de passe, vous serez probablement ok. Le point du sel, est de sorte que vous ne pouvez pas utiliser la norme arc-en-ciel de la table pour résoudre tous les mot de passe dans la base de données. Donc, si vous appliquez une autre de sel pour chaque mot de passe (même si elle n'est pas aléatoire), l'attaquant aurait fait pour calculer une nouvelle table arc-en-ciel pour chaque mot de passe, car chaque mot de passe utilise un autre sel.
À l'aide d'un sel avec plus d'entropie n'aide pas beaucoup, parce que le pirate dans ce cas, est supposé avoir déjà la base de données. Puisque vous avez besoin pour être en mesure de recréer la table de hachage, vous devez déjà savoir ce que le sel est. Donc, vous avez à stocker le sel, ou les valeurs qui constituent le sel dans votre fichier de toute façon. Dans des systèmes comme Linux, la méthode pour obtenir le sel est connu, n'est donc pas l'utilité de faire un secret de sel. Vous devez supposer que l'attaquant qui a vos valeurs de hachage, ne sait probablement votre sel valeurs.
La force d'une fonction de hachage n'est pas déterminée par son entrée!
À l'aide d'un sel qui est connu de l'attaquant rend évidemment la construction d'un arc-en-ciel de la table (en particulier pour les codée en dur comme les noms d'utilisateur racine) plus attrayant, mais il ne s'affaiblit pas la de hachage. À l'aide d'un sel qui est inconnu de l'attaquant sera de rendre le système plus difficile à attaquer.
La concaténation d'un nom d'utilisateur et le mot de passe peut encore fournir une entrée pour un intelligent arc-en-ciel de la table, donc à l'aide d'un sel d'une série de nombres pseudo-aléatoires de caractères stockées avec le hachage de mot de passe est probablement une meilleure idée. Comme une illustration, si j'avais le nom d'utilisateur "pomme de terre" et le mot "bière", la concaténation d'entrée pour votre hash est "potatobeer", qui est un accès raisonnable pour un arc-en-ciel de la table.
Modification du sel à chaque fois que l'utilisateur modifie son mot de passe peut vous aider à vaincre prolongée attaques, de même que l'exécution d'une raisonnable stratégie de mot de passe, par exemple, des majuscules et des minuscules, ponctuation, min longueur, changer après n semaines.
Je dirais, cependant, votre choix de digérer l'algorithme est le plus important. L'utilisation de SHA-512 va s'avérer plus de douleur pour quelqu'un de la génération d'un arc-en-ciel de la table que MD5, par exemple.
Sel doit avoir autant d'entropie que possible pour s'assurer que si une donnée d'entrée de la valeur hachée plusieurs fois, la valeur de hachage sera, aussi près que possible, toujours différentes.
L'aide constante évolution valeurs du sel avec autant d'entropie que possible dans le sel permet de s'assurer que la probabilité de hachage (par exemple, mot de passe + sel) va produire entièrement différentes valeurs de hachage.
Le moins d'entropie dans le sel, plus vous aurez de chance de générer la même valeur salt, ainsi plus vous aurez de chance de générer la même valeur de hachage.
Il est de la nature de la valeur de hachage d'être "constante" lorsque l'entrée est connu "et " constant" qui permettent à des attaques par dictionnaire ou rainbow tables pour être efficace. En faisant varier la valeur résultant de hachage autant que possible (en utilisant à haute entropie valeurs du sel) veille à ce que le hachage de la même entrée+random-sel va produire beaucoup de différents résultats de valeur de hachage, ainsi à l'encontre de (ou au moins de réduire considérablement l'efficacité de l') arc-en-ciel de la table des attaques.
L'entropie est le point de concentration de Sel.
Si il est simple et reproductible "mathématiques" derrière sel, que c'est le même que le sel n'est pas là. Juste en ajoutant de la valeur temps devrait être bon.