La nécessité de cacher le sel pour un hasch

Au travail, nous avons deux théories concurrentes pour les sels. Les produits sur lesquels je travaille utilisent quelque chose comme un nom d'utilisateur ou un numéro de téléphone pour saler le hachage. Essentiellement quelque chose de différent pour chaque utilisateur mais qui nous est facilement accessible. L'autre produit génère de manière aléatoire un sel pour chaque utilisateur et change chaque fois que l'utilisateur change le mot de passe. Le sel est ensuite chiffré dans la base de données.

Ma question est de savoir si la deuxième approche est vraiment nécessaire? Je peux comprendre d'un point de vue purement théorique qu'il est plus sûr que la première approche, mais qu'en est-il d'un point de vue pratique. À l'heure actuelle, pour authentifier un utilisateur, le sel doit être non chiffré et appliqué aux informations de connexion.

Après y avoir réfléchi, je ne vois tout simplement pas de réel gain de sécurité dans cette approche. Changer le sel d'un compte à un autre rend toujours extrêmement difficile pour quelqu'un d'essayer de forcer brutalement l'algorithme de hachage, même si l'attaquant savait comment déterminer rapidement ce que c'était pour chaque compte. Cela part de l'hypothèse que les mots de passe sont suffisamment forts. (Évidemment, trouver le hachage correct pour un ensemble de mots de passe où ils sont tous à deux chiffres est beaucoup plus facile que de trouver le hachage correct des mots de passe qui sont à 8 chiffres). Suis-je incorrect dans ma logique, ou y a-t-il quelque chose qui me manque?

EDIT: D'accord, voici la raison pour laquelle je pense qu'il est vraiment inutile de crypter le sel. (laissez-moi savoir si je suis sur la bonne voie).

Pour l'explication suivante, nous supposerons que les mots de passe sont toujours 8 caractères et que le sel est 5 et que tous les mots de passe sont composés de lettres minuscules (cela facilite simplement les calculs).

Avoir un sel différent pour chaque entrée signifie que je ne peux pas utiliser la même table arc-en-ciel (en fait, techniquement, je le pourrais si j'en avais une de taille suffisante, mais ignorons cela pour le moment). C'est la vraie clé du sel d'après ce que je comprends, car pour déchiffrer chaque compte, je dois réinventer la roue pour ainsi dire pour chacun. Maintenant, si je sais comment appliquer le sel correct à un mot de passe pour générer le hachage, je le ferais parce qu'un sel étend vraiment simplement la longueur / complexité de la phrase hachée. Je réduirais donc le nombre de combinaisons possibles que j'aurais besoin de générer pour "savoir" que j'ai le mot de passe + sel de 13 ^ 26 à 8 ^ 26 parce que je sais ce qu'est le sel. Maintenant, cela rend les choses plus faciles, mais toujours très difficiles.

Donc, sur le cryptage du sel. Si je sais que le sel est crypté, je n'essaierais pas de le décrypter (en supposant que je sache qu'il a un niveau de cryptage suffisant) en premier. Je l'ignorerais. Au lieu d'essayer de comprendre comment le déchiffrer, revenons à l'exemple précédent, je générerais simplement une table arc-en-ciel plus grande contenant toutes les clés du 13 ^ 26. Ne pas connaître le sel me ralentirait certainement, mais je ne pense pas que cela ajouterait la tâche monumentale d'essayer de déchiffrer d'abord le cryptage du sel. C'est pourquoi je ne pense pas que cela en vaille la peine. Pensées?

Voici un lien décrivant la durée de conservation des mots de passe sous une attaque par force brute: http://www.lockdown.co.uk/?pg=combi

La réponse ici est de vous demander de quoi vous essayez vraiment de vous protéger? Si quelqu'un a accès à votre base de données, il a alors accès aux sels cryptés et il a probablement également accès à votre code. Avec tout cela pourraient-ils décrypter les sels cryptés? Si tel est le cas, le cryptage est de toute façon pratiquement inutile. Le sel est vraiment là pour faire en sorte qu'il ne soit pas possible de former une table arc-en-ciel pour déchiffrer toute votre base de données de mots de passe en une seule fois si elle est brisée. De ce point de vue, tant que chaque sel est unique, il n'y a pas de différence, une attaque par force brute serait nécessaire avec vos sels ou les sels cryptés pour chaque mot de passe individuellement.

Cacher un sel n'est pas nécessaire.

Un sel différent doit être utilisé pour chaque hachage. En pratique, cela est facile à réaliser en obtenant 8 octets ou plus à partir du générateur de nombres aléatoires de qualité cryptographique.

D'une réponse précédente de la mienne :

Salt aide à contrecarrer les attaques de dictionnaire pré-calculées.

Supposons qu'un attaquant dispose d'une liste de mots de passe probables. Il peut hacher chacun d'eux et le comparer au hachage du mot de passe de sa victime, et voir s'il correspond. Si la liste est longue, cela peut prendre du temps. Il ne veut pas passer autant de temps sur sa prochaine cible, donc il enregistre le résultat dans un "dictionnaire" où un hachage pointe vers son entrée correspondante. Si la liste des mots de passe est très, très longue, il peut utiliser des techniques comme une Rainbow Table pour gagner de la place.

Cependant, supposons que sa prochaine cible ait salé son mot de passe. Même si l'attaquant sait ce qu'est le sel, sa table précalculée est sans valeur - le sel modifie le hachage résultant de chaque mot de passe. Il doit re-hacher tous les mots de passe de sa liste, en apposant le sel de la cible sur l'entrée. Chaque sel différent nécessite un dictionnaire différent, et si suffisamment de sels sont utilisés, l'attaquant n'aura pas de place pour stocker des dictionnaires pour tous. L'échange d'espace pour gagner du temps n'est plus une option; l'attaquant doit revenir au hachage de chaque mot de passe de sa liste pour chaque cible qu'il veut attaquer.

Il n'est donc pas nécessaire de garder le sel secret. Il suffit de s'assurer que l'attaquant ne dispose pas d'un dictionnaire pré-calculé correspondant à ce sel particulier.

Après avoir réfléchi un peu plus à cela, j'ai réalisé que se tromper en pensant que le sel peut être caché est dangereux. Il est préférable de supposer que le sel ne peut pas être caché et de concevoir le système pour qu'il soit sûr malgré cela. Je donne une explication plus détaillée dans une autre réponse.

Cependant, les recommandations récentes du NIST encouragent l'utilisation d'un "sel" secret supplémentaire (j'ai vu d'autres appeler ce "poivre" secret supplémentaire). Une itération supplémentaire de la dérivation de clé peut être effectuée en utilisant ce secret comme sel. Plutôt que d'augmenter la force contre une attaque de recherche pré-calculée, ce tour protège contre la devinette de mot de passe, tout comme le grand nombre d'itérations dans une bonne fonction de dérivation de clé. Ce secret ne sert à rien s'il est stocké avec le mot de passe haché; il doit être géré comme un secret, ce qui peut être difficile dans une grande base de données d'utilisateurs.

Ma compréhension du "sel" est que cela rend la fissuration plus difficile, mais cela n'essaie pas de cacher les données supplémentaires. Si vous essayez d'obtenir plus de sécurité en rendant le sel "secret", alors vous voulez vraiment plus de bits dans vos clés de chiffrement.

La deuxième approche n'est que légèrement plus sûre. Les sels protègent les utilisateurs des attaques par dictionnaire et des attaques de table arc-en-ciel. Ils rendent plus difficile pour un attaquant ambitieux de compromettre l'ensemble de votre système, mais sont toujours vulnérables aux attaques ciblées sur un utilisateur de votre système. Si vous utilisez des informations accessibles au public, comme un numéro de téléphone, et que l'attaquant en prend conscience , vous lui avez enregistré une étape de son attaque. Bien sûr, la question est sans objet si l'attaquant obtient toute votre base de données, vos sels et tout.

EDIT: Après avoir relu cette réponse et certains des commentaires, il me semble qu'une partie de la confusion peut être due au fait que je ne compare que les deux cas très spécifiques présentés dans la question: sel aléatoire vs. sel non aléatoire. La question de l' utilisation d'un numéro de téléphone comme sel est sans objet si l'attaquant obtient l'intégralité de votre base de données, pas la question de l'utilisation d'un sel du tout.

... quelque chose comme un nom d'utilisateur ou un numéro de téléphone pour saler le hachage. ...

Ma question est de savoir si la deuxième approche est vraiment nécessaire? Je peux comprendre d'un point de vue purement théorique qu'il est plus sûr que la première approche, mais qu'en est-il d'un point de vue pratique?

D'un point de vue pratique, un sel est un détail de mise en œuvre. Si jamais vous changez la façon dont les informations utilisateur sont collectées ou conservées - et que les noms d'utilisateur et les numéros de téléphone changent parfois, pour utiliser vos exemples exacts - vous avez peut-être compromis votre sécurité. Voulez-vous qu'un tel changement tourné vers l'extérieur pose des problèmes de sécurité beaucoup plus profonds?

L'arrêt de l'exigence selon laquelle chaque compte dispose d'un numéro de téléphone doit-il impliquer un examen de sécurité complet pour vous assurer que vous n'avez pas ouvert ces comptes à un compromis de sécurité?

Un sel caché n'est plus du sel. C'est du poivre. Il a son utilité. C'est différent du sel.

Pepper est une clé secrète ajoutée au mot de passe + sel qui transforme le hachage en un HMAC (Hash Based Message Authentication Code). Un hacker ayant accès à la sortie de hachage et au sel peut théoriquement par force brute deviner une entrée qui générera le hachage (et passera donc la validation dans la zone de texte du mot de passe). En ajoutant du poivre, vous augmentez l'espace du problème d'une manière cryptographiquement aléatoire, rendant le problème insoluble sans matériel sérieux.

Pour plus d'informations sur le poivre, cliquez ici .

Voir aussi hmac .

Voici un exemple simple montrant pourquoi il est mauvais d'avoir le même sel pour chaque hachage

Considérez le tableau suivant

UserId  UserName,   Password
     1  Fred       Hash1 =  Sha(Salt1+Password1)    
     2  Ted        Hash2 =  Sha(Salt2+Password2)    

Cas 1 où salt 1 est identique à salt2 Si Hash2 est remplacé par Hash1, l'utilisateur 2 peut se connecter avec le mot de passe de l'utilisateur 1

Cas 2 lorsque salt 1 n'est pas le même salt2 Si Hash2 est remplacé par Hash1, l'utilisateur2 ne peut pas se connecter avec le mot de passe de l'utilisateur 1.

Il existe deux techniques, avec des objectifs différents:

• Le «sel» est utilisé pour faire crypter différemment deux mots de passe égaux. De cette façon, un intrus ne peut pas utiliser efficacement une attaque par dictionnaire contre toute une liste de mots de passe chiffrés.

• Le "secret" (partagé) est ajouté avant le hachage d'un message, de sorte qu'un intrus ne peut pas créer ses propres messages et les faire accepter.

J'ai tendance à cacher le sel. J'utilise 10 bits de sel en ajoutant un nombre aléatoire de 1 à 1024 au début du mot de passe avant de le hacher. En comparant le mot de passe que l'utilisateur a entré avec le hachage, je boucle de 1 à 1024 et j'essaye toutes les valeurs possibles de salt jusqu'à ce que je trouve la correspondance. Cela prend moins de 1/10 de seconde. J'ai eu l'idée de le faire de cette façon à partir de PHP password_hash et password_verify . Dans mon exemple, le «coût» est de 10 pour 10 morceaux de sel. Ou d'après ce qu'un autre utilisateur a dit, le "sel" caché est appelé "poivre". Le sel n'est pas chiffré dans la base de données. C'est une brute forcée. Cela rendrait la table arc-en-ciel nécessaire pour inverser le hachage 1000 fois plus grand. J'utilise sha256 parce qu'il est rapide, mais toujours considéré comme sécurisé.

Vraiment, cela dépend du type d'attaque que vous essayez de protéger vos données.

Le but d'un sel unique pour chaque mot de passe est d'empêcher une attaque par dictionnaire contre toute la base de données de mots de passe.

Crypter le sel unique pour chaque mot de passe rendrait plus difficile le déchiffrement d'un mot de passe individuel, oui, mais vous devez évaluer s'il y a vraiment un avantage. Si l'attaquant, par force brute, trouve que cette chaîne:

Marianne2ae85fb5d

hashes à un hachage stocké dans la base de données, est-il vraiment si difficile de déterminer quelle partie est la passe et quelle partie est le sel?