sel non aléatoire pour hashs

Question

Mise à jour: Je viens d'apprendre de cette question que toute la discussion ci-dessous, je (et je suis sûr d'autres l'ont aussi) était un peu confus: ce que je continue à appeler une table arc en ciel, est en fait appelé une table de hachage. Rainbow Tables sont des créatures plus complexes, et sont en fait une variante de Hellman Chaînes Hash. Bien que je crois que la réponse est toujours la même (puisqu'il ne se résume pas à la cryptanalyse), une partie de la discussion pourrait être un peu biaisé.
La question: « Quels sont les tables arc-en-et comment sont-ils utilisés »

---

En général, je recommande de toujours utiliser une valeur aléatoire forte comme cryptographiquement sel, à utiliser avec des fonctions de hachage (par exemple des mots de passe), par exemple pour protéger contre les attaques de la table arc en ciel.

Mais est-il réellement nécessaire cryptographiquement pour le sel soit au hasard? Est-ce que toute valeur unique (utilisateur unique par, par exemple userId) suffit à cet égard? Il serait en effet empêcher l'utilisation d'une seule table arc-en pour casser les mots de passe (ou plus) dans le système ...
Mais ne manque d'entropie faiblit vraiment la force cryptographique des fonctions de hachage?

---

Remarque, je ne demande pas de savoir pourquoi utiliser le sel, comment le protéger (il n'a pas besoin d'être), en utilisant un seul hachage constante (ne pas), ou quel type de fonction de hachage à utiliser. < br> Juste besoin de sel si l'entropie ou non.

---

Merci pour toutes les réponses à ce jour, mais je voudrais me concentrer sur les domaines que je suis (un peu) moins familiers. Principalement des implications pour la cryptanalyse - Je vous en serais reconnaissant plus si quelqu'un a une entrée de la PoV crypto-mathématique
. De plus, s'il y a des vecteurs supplémentaires qui n'a pas été considéré, c'est une grande entrée aussi (voir le point sur plusieurs Sherohman @ Dave systèmes).
Au-delà, si vous avez une théorie, une idée ou les meilleures pratiques - s'il vous plaît étayer cette thèse soit avec la preuve, le scénario d'attaque, ou des données empiriques. Ou même des considérations valables pour des compromis acceptables ... Je connais les meilleures pratiques (B majuscule P majuscule) sur le sujet, je voudrais prouver quelle valeur cela fournit en fait.

---

EDIT: Quelques réponses vraiment bien ici, mais je pense que comme le dit @ Dave, il se résume à Rainbow Tables pour les noms d'utilisateur communs ... et les noms possibles moins communs aussi. Cependant, si mes noms d'utilisateur sont uniques au monde? Pas nécessairement unique pour mon système, mais par chaque utilisateur - par exemple adresse e-mail.
Il n'y aurait aucun intérêt à construire une RT pour un seul utilisateur (comme souligné @ Dave, le sel n'est pas gardé secret), et cela empêcherait encore le regroupement. Le seul problème serait que je pourrais avoir le même mot de passe e-mail et sur un autre site -. Mais le sel wouldnt empêcher que de toute façon
Ainsi, il revient vers le bas à la cryptanalyse - est l'entropie nécessaire, ou non? (Ma pensée actuelle est ce n'est pas nécessaire d'un point de vue de la cryptanalyse, mais il est d'autres raisons pratiques).

Answer 1

Le sel est traditionnellement stocké comme préfixe pour le mot de passe haché. Cela fait déjà connu à un attaquant ayant accès au hachage de mot de passe. En utilisant le nom d'utilisateur sous forme de sel ou non n'affecte pas que la connaissance et, par conséquent, il n'a pas d'effet sur la sécurité système unique.

Cependant, en utilisant le nom d'utilisateur ou de toute autre sécurité inter-système de valeurs que le sel réduirait contrôlé par l'utilisateur, en tant qu'utilisateur qui avait le même nom d'utilisateur et mot de passe sur plusieurs systèmes qui utilisent le même algorithme de hachage de mot de passe se retrouveraient avec le même mot de passe hachage sur chacun de ces systèmes. Je ne considère pas une responsabilité importante parce que moi, comme un attaquant, essaierais des mots de passe est connu un compte cible d'avoir utilisé d'abord sur d'autres systèmes avant d'essayer tout autre moyen de compromettre le compte. hash ne me Identiques dire à l'avance que le mot de passe connu fonctionnerait, ils ne feraient pas l'attaque réelle plus facile. (Notez, cependant, qu'une comparaison rapide des bases de données de compte fournirait une liste des cibles plus prioritaires, car il me dire qui est et qui ne pas réutiliser les mots de passe.)

Le plus grand danger de cette idée est que les noms d'utilisateur sont souvent réutilisés - à peu près tous les sites que vous aimez visiter aura un compte d'utilisateur nommé « Dave », par exemple, et « admin » ou « root » sont encore plus fréquents - ce qui rendrait la construction de tables arc-en-ciblant les utilisateurs avec les noms communs beaucoup plus facile et plus efficace.

pourrait être efficacement deux de ces défauts en ajoutant une deuxième valeur de sel (soit fixe et caché ou exposé comme le sel standard) au mot de passe avant le hachant, mais, à ce moment-là, vous pouvez aussi bien être juste à l'aide entropique norme sel de toute façon au lieu de travailler le nom d'utilisateur en elle.

Edité à ajouter: Beaucoup de gens parlent de l'entropie et si l'entropie dans le sel est important. Il est, mais pas pour la raison la plupart des commentaires sur ce semblent penser.

La pensée générale semble être que l'entropie est importante pour que le sel sera difficile pour un attaquant de deviner. Ceci est incorrect et, en fait, tout à fait hors de propos. Comme il a été souligné plusieurs fois par différentes personnes, attaques qui seront affectées par le sel ne peut être faite par une personne avec la base de données de mot de passe et une personne avec la base de données de mot de passe peut il suffit de regarder pour voir ce que le sel de chaque compte est. Que ce soit devinables ou non n'a pas d'importance quand vous pouvez regarder trivialement vers le haut.

La raison pour laquelle l'entropie est important est d'éviter le regroupement des valeurs de sel. Si le sel est basé sur le nom d'utilisateur et vous savez que la plupart des systèmes auront un compte nommé soit « root » ou « admin », alors vous pouvez faire une table arc-en-pour ces deux sels et craquerez la plupart des systèmes. Si, d'autre part, un est utilisé et les valeurs aléatoires sel 16 bits aléatoires ont à peu près même la distribution, alors vous avez besoin d'une table arc-en-pour tous les 2 ^ 16 sels possibles.

Il est pas d'empêcher l'attaquant de savoir ce qui est, il est de ne pas leur donner le sel d'un compte individuel de la grande, cible la graisse d'un sel unique qui sera utilisé sur une proportion importante de cibles potentielles.

Answer 2

L'utilisation d'un sel de haute entropie est absolument nécessaire pour stocker les mots de passe en toute sécurité.

Prenez mon nom d'utilisateur « gs » et l'ajouter à mon mot de passe « MonMotdePasse » donne gsMyPassword. Ceci est facilement cassé à l'aide d'une table arc-en-parce que si le nom d'utilisateur n'a pas obtenu suffisamment d'entropie il se pourrait que cette valeur est déjà enregistrée dans la table d'arc en ciel, surtout si le nom d'utilisateur est court.

Un autre problème sont les attaques où vous savez qu'un utilisateur participe à deux ou plusieurs services. Il y a beaucoup de noms d'utilisateur communs, sans doute les plus importants sont admin et racine. Si quelqu'un a créé une table d'arc en ciel qui ont des sels avec les noms d'utilisateur les plus communs, il pourrait les utiliser pour compromettre des comptes.

Ils avaient un sel 12 bits. 12 bits sont 4096 combinaisons différentes. Cela n'a pas été suffisamment en sécurité parce que que beaucoup d'informations peuvent être facilement stockées aujourd'hui . De même pour les 4096 noms d'utilisateur les plus utilisés. Il est probable que quelques-unes de vos utilisateurs le choix d'un nom d'utilisateur qui appartient aux noms d'utilisateurs les plus courants.

J'ai trouvé cette mot de passe vérificateur qui fonctionne l'entropie de votre mot de passe. Ayant plus faible entropie dans les mots de passe (comme en utilisant les noms d'utilisateur), il est beaucoup plus facile pour les rainbowtables comme ils essaient de couvrir au moins tous les mots de passe à faible entropie, car ils sont plus susceptibles de se produire.

Answer 3

Il est vrai que le nom d'utilisateur seul peut être problématique puisque les gens peuvent partager les noms d'utilisateur entre les différents site. Mais il devrait être plutôt sans problèmes si les utilisateurs avaient un nom différent sur chaque site. Alors pourquoi ne pas simplement le rendre unique sur chaque site. Hacher le mot de passe un peu comme ça

fonction de hachage ( "www.yourpage.com /" + nom d'utilisateur + "/" + mot de passe)

Cela devrait résoudre le problème. Je ne suis pas maître de cryptanalyse, mais je doute que le fait que nous n'utilisons l'entropie élevée serait le hachage une plus faible.

Answer 4

J'aime utiliser à la fois: un échantillon aléatoire de haute entropie de sel par enregistrement, 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 ne supprime le cas marginal où quelqu'un copie leur sel et hachage à un autre enregistrement avec l'intention de remplacer le mot de passe avec leur propre.

(Certes, il est difficile de penser à une situation où cela vaut, mais je ne vois pas de mal à la ceinture et bretelles en matière de sécurité.)

Answer 5

Si l'on connaît le sel ou facilement devinable, vous n'avez pas augmenté la difficulté d'une attaque par dictionnaire. Il peut même être possible de créer une table arc-en-modifié qui prend un sel « constante » en compte.

En utilisant des sels uniques augmente la difficulté de VRAC attaques de dictionnaire.

Avoir valeur unique de sel cryptographiquement forte serait idéal.

Answer 6

Je dirais que tant que le sel est différent pour chaque mot de passe, vous serez probablement ok. Le point de sel, est que vous ne pouvez pas utiliser la table arc-en-standard pour résoudre tous les mot de passe dans la base de données. Donc, si vous appliquez un sel différent à chaque mot de passe (même si elle est pas au hasard), l'attaquant aurait essentiellement pour calculer une nouvelle table arc-en-pour chaque mot de passe, car chaque mot de passe utilise un sel différent.

L'utilisation d'un sel avec plus d'entropie ne contribue pas beaucoup, parce que l'attaquant dans ce cas est supposé avoir déjà la base de données. Puisque vous devez être en mesure de recréer le hachage, vous devez savoir déjà ce que le sel est. Donc, vous devez stocker le sel, ou les valeurs qui composent le sel dans votre dossier de toute façon. Dans les systèmes comme Linux, la méthode pour obtenir le sel est connu, donc il n'y a pas à avoir un sel secret. Vous devez supposer que l'attaquant qui a vos valeurs de hachage, sait probablement vos valeurs de sel ainsi.

Answer 7

La force d'une fonction de hachage n'est pas déterminée par son entrée!

L'utilisation d'un sel qui est connu pour l'attaquant fait construire une table arc-en-(en particulier pour les noms d'utilisateur codés en dur comme root ) plus attrayant, mais il ne peut évidemment faiblit pas hachage . L'utilisation d'un sel qui est inconnu à l'attaquant rendra le système plus difficile à attaquer.

La concaténation d'un nom d'utilisateur et mot de passe peut encore fournir une entrée pour une table arc-en-intelligente, donc l'utilisation d'un sel d'une série de caractères pseudo-aléatoires, stockées avec le mot de passe est probablement une hashed meilleure idée. A titre d'illustration, si j'avais le nom d'utilisateur « pomme de terre » et le mot de passe « bière », l'entrée concaténés pour votre hachage est « potatobeer », qui est une entrée raisonnable pour une table d'arc en ciel.

Modification du sel à chaque fois que l'utilisateur modifie son mot de passe pourrait aider à vaincre les attaques prolongées, tout comme l'application d'une politique de mot de passe raisonnable, par exemple cas mixte, la ponctuation, la longueur min, changement après n semaines.

Cependant, je dirais que votre choix de l'algorithme digest est plus important. L'utilisation de SHA-512 va se révéler être plus d'une douleur pour quelqu'un générer une table arc-en-MD5 que, par exemple.

Answer 8

Le sel doit avoir autant d'entropie que possible pour faire en sorte que si une valeur d'entrée donnée à plusieurs reprises être haché, la valeur de hachage résultante sera, aussi proche que possible grâce, toujours différent.

En utilisant les valeurs de sel en constante évolution avec autant d'entropie que possible dans le sel veillera à ce que la probabilité de hachage (par exemple, le mot de passe + sel) produira des valeurs de hachage totalement différentes.

Le moins entropie dans le sel, plus vous aurez de chance de générer la même valeur de sel, comme ainsi plus de chance que vous avez de générer la même valeur de hachage.

Il est la nature de la valeur de hachage étant « constante » lorsque l'entrée est connue et « constante » qui permettent aux attaques de dictionnaire ou tables arc-en-si efficace. En faisant varier la valeur de hachage résultante autant que possible (en utilisant des valeurs de sel entropie élevée) assure le hachage de la même entrée + sel aléatoire produira beaucoup de différents résultats de la valeur de hachage, défaisant ainsi (ou au moins réduire considérablement l'efficacité de) table d'arc attaques.

Answer 9

Entropy est le point de la valeur de sel.

S'il y a une simple et reproductible « mathématiques » derrière le sel, que c'est le même que le sel est pas là. Juste valeur ajoutée de temps devrait être bon.