Sel non aléatoire pour les hachages de mot de passe

Question

Mise à JOUR: j'ai appris récemment à partir 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 (depuis il ne marche pas descendre à la cryptanalyse), quelques éléments de la discussion peut-être un peu biaisé.
La question: "Quelles sont les 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 génial d'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. 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.)

Answer 1

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

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

Answer 2

À 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-peu 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é ce 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.

Answer 3

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 ça

hashfunction("www.yourpage.com/"+username+"/"+mot de passe)

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

Answer 4

J’aime utiliser tous les deux : un haut-entropie aléatoire par record sel, ainsi que l’ID unique de l’enregistrement lui-même.

Bien que cela n’ajoute pas grand chose à la sécurité contre les attaques de dictionnaire, etc., il supprime le cas marginaux où quelqu'un copie leur sel et hachage dans un autre dossier dans le but de remplacer le mot de passe avec leurs propres.

(Il est vrai que c’est difficile d’imaginer une situation où c’est le cas, mais je ne vois pas de mal à ceintures et bretelles quand il s’agit de sécurité).

Answer 5

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 root) plus attrayante, mais il n'a pas d'affaiblir le 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 la n des 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.