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

89

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

Avide
la source
Je dois dire que je suis confus par la plupart des réponses ci-dessous. Le point principal de l'utilisation du sel est simplement d'empêcher l'attaque de la table arc-en-ciel, donc tout ce qui est unique à l'utilisateur doit faire car cela oblige l'attaquant à recréer une table arc-en-ciel pour chaque sel. mon 2c.
Goran
Si le sel est nécessaire pour par exemple. site, vous avez souvent des identifiants dans les URL. Si l'attaquant sait (et nous supposons qu'il le fait) que le sel de mot de passe est userid + username, il est assez facile de modifier l'attaque pour éviter la valeur de salt.
dmajkic le
@dmajkic, salt est destiné à empêcher les attaques RT et à différencier les mêmes mots de passe pour différents utilisateurs. C'est une donnée, même avec les noms d'utilisateur.
AviD
@AviD: C'est vrai. Mais si je connais mon hachage pour mon pass, et que je sais que salt est mon nom d'utilisateur, je peux facilement créer une valeur de passe hachée pour n'importe quel mot du dictionnaire et la comparer à quelqu'un d'autre. C'est pourquoi le temps est meilleur que le nom d'utilisateur.
dmajkic le
1
Je viens de trouver un article sur le site Web du PHP Security Consortium qui, dans son exemple, utilise un nombre aléatoire haché md5 comme le sel phpsec.org/articles/2005/password-hashing.html
helloworlder

Réponses:

156

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.

Dave Sherohman
la source
D'accord. Je mettrais davantage l'accent sur la réutilisation des noms d'utilisateur, car je pense que c'est l'attaque la plus susceptible de réussir contre des systèmes hypothétiques utilisant le nom d'utilisateur comme sel, qui aurait échoué contre un système utilisant un sel aléatoire.
Steve Jessop le
J'apprécie votre point de vue sur la sécurité intersystème. De plus, je suppose qu'à l'avenir, il n'est pas improbable de voir des tables arc-en-ciel spécifiques à l'utilisateur ...
AviD
@AviD: Vous pensez que oui? C'est un vecteur d'attaque assez spécifique.
David Grant
2
Pas pour générer des sels, non. Les seules attaques affectées par le sel sont celles effectuées directement contre les mots de passe hachés. Une attaque ne peut pas faire ce genre d'attaque à moins d'avoir une copie de votre base de données de mots de passe, qui contiendra également les sels. Puisque l'attaquant aura déjà les sels en sa possession, ils ne nécessitent qu'une entropie suffisante pour éviter d'avoir plusieurs mots de passe hachés avec le même sel, ce que tout RNG (P) basique fournira.
Dave Sherohman le
3
@ acidzombie24: Utiliser un seul sel fixe (généralement appelé "nonce" dans mon expérience) pour tous les mots de passe est moins sûr que d'utiliser un sel aléatoire unique pour chaque mot de passe, car cela permet toujours à un attaquant de déterminer de manière triviale si deux comptes ou plus se partagent le même mot de passe. D'autre part, le nonce serait probablement stocké dans votre code plutôt que dans la base de données, donc un attaquant qui ne possède votre base de données ne sera pas y avoir accès; à cause de cela, l'option la plus sûre est d'utiliser à la fois un nonce à l'échelle du système (stocké dans le code) et un sel par mot de passe (stocké dans la base de données).
Dave Sherohman
29

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.

Georg Schölly
la source
+1 pour un bon point, cependant, vous sont parle d'une potentiellement énorme table arc en ciel. Pour couvrir toutes les valeurs de longueur de gsMyPassword (en supposant des caractères alphanumériques mixtes), il faut 36 ^ 12 lignes dans le tableau!
David Grant
En guise de suivi: le projet de table arc-en-ciel distribuée a 63 970 hachages fissurés, mais 36 ^ 12 est 4 738 381 338 321 616 896!
David Grant
Merci, et cela a du sens - mais comme l'a souligné M. PotatoHead, vous élargissez toujours votre espace au-delà de toute possibilité raisonnable de craquer avec RT. De plus, en supposant que mes noms d'utilisateur contiennent au moins 6 à 8 caractères - quelle valeur supplémentaire nécessaire l'entropie fournit-elle?
AviD le
@Potato: vous supposez une table arc-en-ciel contenant toutes les combinaisons possibles de caractères alphanumériques. Cela n'a pas besoin d'être le cas, une table arc-en-ciel efficace contiendra des hachages pour les mots de passe / hachages courants. Salt est là pour protéger contre les attaques de dictionnaire ou la combinaison arc-en-ciel / dictionnaire.
Guillaume le
3
Utiliser le nom d'utilisateur comme sel est également une mauvaise idée pour les systèmes où il existe un compte à privilèges élevés nommé de manière prévisible: "Administrator" sur Windows, "root" sur * nix, "sa" dans MSSQL, etc.
personne le
8

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.

konne
la source
Je crois que vous avez raison de dire que c'est suffisant. Cependant, étant donné que les hachages sont un domaine mathématique compliqué et qu'il est très bien possible que les sels à faible entropie rendent les hachages plus faciles à deviner à l'avenir, (d'autant plus que les hachages sont cassés), je ne parierais pas sur la sécurité, quand le une solution plus sûre n'est pas beaucoup plus chère.
Georg Schölly
7

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é.)

teedyay
la source
J'aime l'idée de lier le mot de passe à l'utilisateur. Mais si l'attaquant peut changer le mot de passe, il peut sûrement aussi changer l'identifiant.
Georg Schölly
Cela dépend de l'ID: j'utilise la clé primaire de la table, que vous ne pouvez pas vraiment changer à volonté. TBH, si le hacker écrit dans votre base de données, vous avez déjà de gros problèmes ...
teedyay
3
Non, j'aime ça. Un attaquant est souvent un «initié». Je pourrais imaginer des scénarios où ce qu'il recherche n'est pas dans la base de données, mais s'il peut écraser les informations d'identification dans la base de données, il peut s'authentifier pour faire ce qu'il veut.
erickson
1
Bon point. Nous trouvons qu'il est de plus en plus difficile d'ajouter le premier utilisateur à une nouvelle base de données: nous avons effectivement rendu nos applications si sécurisées que nous pouvons à peine les pirater nous-mêmes. [De plus, utilisez un sel spécifique à l'application pour ne pas pouvoir copier les informations d'identification d'une base de données vers une autre.]
teedyay
Enfin, j'ai trouvé quelqu'un disant ceci: ajouter quelque chose de spécifique à l'utilisateur au sel. Cela évite à un intrus de copier certaines informations d'identification à un autre utilisateur, et empêche également un pirate de deviner un mot de passe s'il parvient à atteindre votre champ de hachage et de sel dans la table. Une autre chose que j'aime faire: ne pas utiliser un nombre rond d'itérations dans le hachage. Ne faites pas 10 km ou 20 km, mais plutôt quelque chose comme 19835.
Andrew
3

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.

HUAGHAGUAH
la source
2
L'intérêt de la table arc-en-ciel est que les valeurs sont pré-générées, et que si vous générez la table pour une valeur (par exemple, un mot de passe) PLUS une constante donnée, c'est une table entièrement différente, et vous pourriez aussi bien essayez directement le résultat du hachage. :)
David Grant
1
Un hachage constant ne vaut rien. Tous les mots de passe peuvent être déchiffrés en utilisant une seule table arc-en-ciel. Le but du sel est qu'il est impossible de créer une table arc-en-ciel.
Georg Schölly
1
@gs - Je ne vois pas pourquoi vous ne pouvez pas construire une table arc-en-ciel qui "inclut" les effets d'un sel constant. L'espace d'attaque (le mot de passe) n'a pas changé, donc la table n'aura pas besoin de s'agrandir, il suffit d'être recalculée.
HUAGHAGUAH
@Potato - dépend du compromis. Si les connexions 20k de votre entreprise ont toutes été hachées avec le même sel constant, il peut être moins coûteux de calculer une nouvelle table arc-en-ciel que de les attaquer par dictionnaire toutes individuellement. D'où mon accent sur "BULK".
HUAGHAGUAH
3

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.

Kibbee
la source
3
"Le but du sel, c'est que vous ne pouvez pas utiliser la table arc-en-ciel standard pour résoudre tous les mots de passe de la base de données". Je ne suis pas d'accord. Le fait est que vous ne pouvez pas utiliser une table arc-en-ciel standard pour résoudre un mot de passe. Si le sel est le nom d'utilisateur, alors la table arc-en-ciel de "root" pourrait casser le pw de root.
Steve Jessop le
C'est probablement la seule règle qui compte vraiment. En gros, vous voulez que le mot de passe soit quelque chose d'unique sur votre système, mais peu importe ce que c'est. Cela pourrait quand même être quelque chose de simple. Vous n'avez pas besoin de beaucoup d'entropie.
Kibbee
C'était aussi ma pensée - mais je suis resté coincé sur le "probablement bien". Je ne vois toujours pas cette théorie prouvée - ou du moins vérifiée qu'il n'y a pas d'implications de cryptanalyse.
AviD
@onebyone: Si le sel consiste en un nom d'utilisateur + une valeur locale constante (j'utilise souvent ':'), cela ruine toujours les RT standardisés, à moins qu'il n'y en ait une variété qui inclut des noms d'utilisateur communs et des valeurs de sel statiques communes. Je soupçonne plutôt que ce n'est pas le cas.
nsayer
Avec nsayer. Vous pouvez utiliser une chaîne constante à l'échelle du système, pour laquelle il n'y aurait pas de RT prégénéré, comme # (D83d8, avec le nom d'utilisateur comme sel, et cela empêcherait probablement toute attaque de table arc-en-ciel.
Kibbee
3

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.

David Grant
la source
La force de la fonction ne change pas, mais la sortie change définitivement. Si l'entrée peut être influencée ou connue, alors peut-être que quelque chose peut être déduit de la valeur de hachage. Voilà le risque.
Martin Carpenter
@Martin: La seule chose que vous devriez pouvoir déduire de la valeur de hachage si vous avez ou non une correspondance! Mettre "roota" ou "rootb" (où "a" et "b" représentent le mot de passe) dans une fonction de hachage vous donnera une sortie radicalement différente.
David Grant
Les sels sont connus d'un attaquant utilisant des tables arc-en-ciel.
Georg Schölly
Le serveur doit connaître le sel non chiffré (pour vérifier le mot de passe par rapport au hachage), ainsi on peut prendre pour acquis qu'un attaquant a accès au sel, ou peut l'obtenir très facilement.
Georg Schölly
Bien, à droite, c'est une donnée - pour être plus précis, je voulais dire la force du cryptosystème global (ou -sous-système, par rapport aux hachages).
AviD le
1

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.

CraigTP
la source
Encore une fois, je ne fais pas référence à l'utilisation d'un seul sel constant - plutôt une valeur non aléatoire, mais unique à l'utilisateur. Par exemple, userId.
AviD le
Le fait est que votre valeur de sel ne doit jamais être constante. Chaque chose que vous hachez, que la même valeur «d'entrée» ou non, ait un sel différent. Dave Sherohman explique les inconvénients de l'utilisation même de valeurs uniques à l'utilisateur qui restent essentiellement les mêmes à chaque calcul de hachage.
CraigTP
-1

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.

dmajkic
la source
Je ne comprends pas ce commentaire. Vous dites "utiliser l'entropie", puis: "utiliser le temps" ??
Martin Carpenter
si le nom d'utilisateur est utilisé pour le sel, ce n'est pas assez entropique. Mais si vous utilisez le nom d'utilisateur + la date actuelle, c'est le cas, car il est difficile de deviner quand exactement le sel a été créé.
dmajkic le
«assez entropique» est subjectif; c'est votre norme. Baser cette valeur sur le temps peut ne pas être adéquat.
Martin Carpenter le
Il n'y a pas de "vrai hasard absolu". C'est à nous de dire quand c'est "assez bien". Si vous pensez que dans ce cas, le temps n'est pas suffisant, utilisez autre chose. stackoverflow.com/questions/84556/…
dmajkic
En fait, le point essentiel est de rendre chaque résultat de hachage unique - afin d'éviter (a) les attaques de table arc-en-ciel et (b) l'identification de mot de passe identique. La question est de savoir à quoi d'autre l'entropie est-elle nécessaire, voire pas du tout?
AviD le