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

MISE À JOUR: J'ai récemment appris de cette question que dans toute la discussion ci-dessous, j'étais un peu déroutant (et je suis sûr que d'autres l'ont fait aussi): ce que je n'arrête pas d'appeler une table arc-en-ciel, s'appelle en fait une table de hachage. Les tables arc-en-ciel sont des créatures plus complexes et sont en fait une variante de Hellman Hash Chains. Bien que je pense que la réponse soit toujours la même (puisqu'elle ne se résume pas à la cryptanalyse), une partie de la discussion pourrait être un peu biaisée.
La question: " Que sont les tables arc-en-ciel et comment sont-elles utilisées? "

En règle générale, je recommande toujours d'utiliser une valeur aléatoire cryptographiquement forte comme salt, à utiliser avec des fonctions de hachage (par exemple pour les mots de passe), comme pour se protéger contre les attaques Rainbow Table.

Mais est-il réellement nécessaire d'un point de vue cryptographique que le sel soit aléatoire? Une valeur unique (unique par utilisateur, par exemple userId) suffirait-elle à cet égard? Cela empêcherait en fait d'utiliser une seule Rainbow Table pour déchiffrer tous (ou la plupart) les mots de passe du système ...
Mais le manque d'entropie affaiblit-il vraiment la force cryptographique des fonctions de hachage?

Notez que je ne demande pas pourquoi utiliser le sel, comment le protéger (cela n'a pas besoin de l'être), en utilisant un seul hachage constant (non), ou quel type de fonction de hachage utiliser.
Juste si le sel a besoin d'entropie ou non.

Merci à tous pour les réponses jusqu'à présent, mais j'aimerais me concentrer sur les domaines que je connais (un peu) moins. Principalement des implications pour la cryptanalyse - j'apprécierais le plus si quelqu'un a une contribution du PoV crypto-mathématique.
De plus, s'il y a des vecteurs supplémentaires qui n'avaient pas été pris en compte, c'est également une excellente contribution (voir le point @Dave Sherohman sur plusieurs systèmes).
Au-delà de cela, si vous avez une théorie, une idée ou une meilleure pratique, veuillez les soutenir avec une preuve, un scénario d'attaque ou des preuves empiriques. Ou même des considérations valables pour des compromis acceptables ... Je connais les meilleures pratiques (majuscule B majuscule P) sur le sujet, j'aimerais prouver quelle valeur cela apporte réellement.

EDIT: Quelques très bonnes réponses ici, mais je pense que, comme le dit @Dave, cela revient à Rainbow Tables pour les noms d'utilisateurs courants ... et éventuellement les noms moins courants aussi. Cependant, que se passe-t-il si mes noms d'utilisateur sont uniques au monde? Pas nécessairement unique pour mon système, mais pour chaque utilisateur - par exemple, adresse e-mail.
Il n'y aurait aucune incitation à créer un RT pour un seul utilisateur (comme @Dave l'a souligné, le sel n'est pas gardé secret), et cela empêcherait toujours le clustering. Le seul problème serait que je pourrais avoir le même email et mot de passe sur un site différent - mais le sel ne l'empêcherait pas de toute façon.
Donc, cela revient à la cryptanalyse - l'entropie est-elle nécessaire ou non? (Ma pensée actuelle est que ce n'est pas nécessaire du point de vue de la cryptanalyse, mais c'est pour d'autres raisons pratiques.)

Le sel est traditionnellement stocké en tant que préfixe du mot de passe haché. Cela le fait déjà savoir à tout attaquant ayant accès au hachage du mot de passe. L'utilisation du nom d'utilisateur comme sel ou non n'affecte pas ces connaissances et, par conséquent, n'aurait aucun effet sur la sécurité d'un seul système.

Cependant, l'utilisation du nom d'utilisateur ou de toute autre valeur contrôlée par l'utilisateur comme salt réduirait la sécurité intersystème, car un utilisateur qui avait le même nom d'utilisateur et le même mot de passe sur plusieurs systèmes utilisant le même algorithme de hachage de mot de passe se retrouverait avec le même hachage de mot de passe sur chacun de ces systèmes. Je ne considère pas cela comme une responsabilité importante car, en tant qu'attaquant, j'essaierais d'abord les mots de passe qu'un compte cible aurait utilisés sur d'autres systèmes avant de tenter tout autre moyen de compromettre le compte. Des hachages identiques me diraient seulement à l'avance que le mot de passe connu fonctionnerait, ils ne faciliteraient pas l'attaque réelle. (Notez, cependant, qu'une comparaison rapide des bases de données de comptes fournirait une liste de cibles de priorité plus élevée, car elle me dirait qui est et qui ne réutilise pas les mots de passe.)

Le plus grand danger de cette idée est que les noms d'utilisateur sont couramment réutilisés - à peu près tous les sites que vous souhaitez visiter auront un compte d'utilisateur nommé "Dave", par exemple, et "admin" ou "root" sont encore plus courants - ce qui rendrait construction de tableaux arc-en-ciel ciblant les utilisateurs avec ces noms communs beaucoup plus facile et plus efficace.

Ces deux failles pourraient être efficacement corrigées en ajoutant une deuxième valeur de sel (fixe et cachée ou exposée comme le sel standard) au mot de passe avant de le hacher, mais, à ce stade, vous pouvez tout aussi bien utiliser du sel entropique standard de toute façon. d'y travailler le nom d'utilisateur.

Edité pour ajouter: Beaucoup de gens parlent d'entropie et de l'importance de l'entropie dans le sel. C'est, mais pas pour la raison que la plupart des commentaires à ce sujet semblent penser.

L'idée générale semble être que l'entropie est importante de sorte que le sel sera difficile à deviner pour un attaquant. Ceci est incorrect et, en fait, totalement hors de propos. Comme cela a été souligné à quelques reprises par diverses personnes, les attaques qui seront affectées par le sel ne peuvent être effectuées que par quelqu'un avec la base de données de mots de passe et quelqu'un avec la base de données de mots de passe peut simplement regarder pour voir quel est le sel de chaque compte. Que ce soit devinable ou non n'a pas d'importance lorsque vous pouvez le rechercher de manière triviale.

La raison pour laquelle l'entropie est importante est d'éviter le regroupement des valeurs de sel. Si le sel est basé sur le nom d'utilisateur et que vous savez que la plupart des systèmes auront un compte nommé "root" ou "admin", alors vous pouvez créer une table arc-en-ciel pour ces deux sels et cela craquera la plupart des systèmes. Si, d'un autre côté, un sel aléatoire de 16 bits est utilisé et que les valeurs aléatoires ont une distribution à peu près égale, alors vous avez besoin d'une table arc-en-ciel pour les 2 ^ 16 sels possibles.

Il ne s'agit pas d'empêcher l'attaquant de savoir ce qu'est le sel d'un compte individuel, il s'agit de ne pas lui donner la grande et grosse cible d'un seul sel qui sera utilisé sur une proportion substantielle de cibles potentielles.

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

Prenez mon nom d'utilisateur «gs» et ajoutez-le à mon mot de passe «MyPassword» donne gsMyPassword. Ceci est facilement cassé en utilisant une table arc-en-ciel car si le nom d'utilisateur n'a pas assez d'entropie, il se peut que cette valeur soit déjà stockée dans la table arc-en-ciel, surtout si le nom d'utilisateur est court.

Un autre problème concerne les attaques où vous savez qu'un utilisateur participe à deux ou plusieurs services. Il existe de nombreux noms d'utilisateurs courants, les plus importants étant probablement admin et root. Si quelqu'un a créé une table arc-en-ciel contenant des sels avec les noms d'utilisateur les plus courants, il pourrait les utiliser pour compromettre les comptes.

Ils avaient un sel 12 bits . 12 bits sont 4096 combinaisons différentes. Ce n'était pas assez sécurisé car une telle quantité d'informations peut être facilement stockée de nos jours . Il en va de même pour les 4096 noms d'utilisateur les plus utilisés. Il est probable que quelques-uns de vos utilisateurs choisiront un nom d'utilisateur qui appartient aux noms d'utilisateur les plus courants.

J'ai trouvé ce vérificateur de mot de passe qui détermine l'entropie de votre mot de passe. Avoir une entropie plus petite dans les mots de passe (comme en utilisant des noms d'utilisateur) facilite beaucoup la tâche pour les tables arc-en-ciel car ils essaient de couvrir au moins tous les mots de passe avec une faible entropie, car ils sont plus susceptibles de se produire.

Il est vrai que le nom d'utilisateur seul peut être problématique car les gens peuvent partager des noms d'utilisateur entre différents sites Web. Mais cela ne devrait pas poser de problème si les utilisateurs avaient un nom différent sur chaque site Web. Alors pourquoi ne pas le rendre unique sur chaque site Web. Hash le mot de passe un peu comme ça

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

Cela 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'utilisions pas une entropie élevée affaiblisse le hachage.

J'aime utiliser les deux: un sel aléatoire par enregistrement à haute entropie, plus l'identifiant unique de l'enregistrement lui-même.

Bien que cela n'ajoute pas grand-chose à la sécurité contre les attaques de dictionnaire, etc., cela supprime le cas marginal où quelqu'un copie son sel et son hachage dans un autre enregistrement avec l'intention de remplacer le mot de passe par le sien.

(Certes, il est difficile de penser à une circonstance où cela s'applique, mais je ne vois aucun mal aux ceintures et aux bretelles en matière de sécurité.)

Si le sel est connu 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-ciel modifiée qui prend en compte un sel «constant».

L'utilisation de sels uniques augmente la difficulté des attaques par dictionnaire BULK.

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

Je dirais que tant que le sel est différent pour chaque mot de passe, tout ira probablement bien. Le point du sel est que vous ne pouvez pas utiliser la table arc-en-ciel standard pour résoudre chaque mot de passe de la base de données. Donc, si vous appliquez un sel différent à chaque mot de passe (même s'il n'est pas aléatoire), l'attaquant devrait essentiellement calculer une nouvelle table arc-en-ciel pour chaque mot de passe, puisque chaque mot de passe utilise un sel différent.

Utiliser un sel avec plus d'entropie n'aide pas beaucoup, car 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 déjà savoir ce qu'est le sel. Vous devez donc stocker le sel, ou les valeurs qui composent le sel dans votre fichier de toute façon. Dans des systèmes comme Linux, la méthode pour obtenir le sel est connue, il est donc inutile d'avoir un sel secret. Vous devez supposer que l'attaquant qui a vos valeurs de hachage connaît probablement également vos valeurs de sel.

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

L'utilisation d'un sel connu de l'attaquant rend évidemment la construction d'une table arc-en-ciel (en particulier pour les noms d'utilisateur codés en dur comme root ) plus attrayante, mais cela n'affaiblit pas le hachage . L'utilisation d'un sel inconnu de l'attaquant rendra le système plus difficile à attaquer.

La concaténation d'un nom d'utilisateur et d'un mot de passe peut toujours fournir une entrée pour une table arc-en-ciel intelligente, donc utiliser un sel d'une série de caractères pseudo-aléatoires, stockés avec le mot de passe haché est probablement une meilleure idée. A titre d'illustration, si j'avais le nom d'utilisateur "potato" et le mot de passe "beer", l'entrée concaténée pour votre hachage est "potatobeer", qui est une entrée raisonnable pour une table arc-en-ciel.

Changer le sel à chaque fois que l'utilisateur change son mot de passe peut aider à vaincre des attaques prolongées, tout comme l'application d'une politique de mot de passe raisonnable, par exemple casse mixte, ponctuation, longueur minimale, changement après n semaines.

Cependant, je dirais que votre choix d'algorithme de résumé est plus important. L'utilisation de SHA-512 va s'avérer plus pénible pour quelqu'un qui génère une table arc-en-ciel que MD5, par exemple.

Le sel doit avoir autant d'entropie que possible pour garantir que si une valeur d'entrée donnée est hachée plusieurs fois, la valeur de hachage résultante sera, aussi proche que possible, toujours différente.

L'utilisation de valeurs de sel en constante évolution avec autant d'entropie que possible dans le sel garantira que la probabilité de hachage (par exemple, mot de passe + sel) produira des valeurs de hachage entièrement différentes.

Moins il y a d'entropie dans le sel, plus vous avez de chances de générer la même valeur de sel, donc plus vous avez de chances de générer la même valeur de hachage.

C'est la nature de la valeur de hachage qui est "constante" lorsque l'entrée est connue et "constante" qui permet aux attaques par dictionnaire ou aux tables arc-en-ciel d'être si efficaces. En faisant varier autant que possible la valeur de hachage résultante (en utilisant des valeurs de sel d'entropie élevées), le hachage de la même entrée + sel aléatoire produira de nombreux résultats de valeur de hachage différents, battant ainsi (ou au moins réduisant considérablement l'efficacité de) la table arc-en-ciel attaques.

L'entropie est le point de la valeur du sel.

S'il y a des «maths» simples et reproductibles derrière le sel, c'est que c'est le même que le sel n'est pas là. Le simple fait d'ajouter de la valeur temporelle devrait convenir.