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

Question

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 hash. Essentiellement, quelque chose de différent pour chaque utilisateur, mais qui est facilement disponible pour nous. L'autre produit génère de manière aléatoire un sel pour chaque utilisateur et change chaque fois que l'utilisateur modifie 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 du point de vue pratique? À l'heure actuelle, pour authentifier un utilisateur, le sel doit être déchiffré et appliqué aux informations de connexion.

Après y avoir réfléchi, je ne vois tout simplement pas un réel gain de sécurité de cette approche. Changer le sel d'un compte à l'autre rend encore extrêmement difficile toute tentative 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 du principe que les mots de passe sont suffisamment forts. (Il est évidemment beaucoup plus facile de trouver le hachage correct pour un ensemble de mots de passe contenant tous les deux chiffres que de trouver le hachage correct de mots de passe de 8 chiffres). Est-ce que je me trompe de logique ou y a-t-il quelque chose qui me manque?

MODIFIER: D'accord, voici donc la raison pour laquelle je pense qu'il est vraiment inutile de chiffrer le sel. (Je sais si je suis sur la bonne voie).

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

Avoir un sel différent pour chaque entrée signifie que je ne peux pas utiliser le même tableau arc-en-ciel (techniquement, je le pourrais si j'en avais un de taille suffisante, mais ignorons cela pour le moment). Ce que je comprends, c’est la vraie clé du succès, car pour craquer tous les comptes, je dois réinventer la roue pour ainsi dire. Maintenant, si je sais comment appliquer le sel correct à un mot de passe pour générer le hachage, je le ferais car un sel étend simplement la longueur / complexité de la phrase hachée. Donc, je couperais le nombre de combinaisons possibles que je devrais générer pour "connaître" 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 ne tenterais 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, pour revenir à l'exemple précédent, je générerais simplement un plus grand tableau arc-en-ciel contenant toutes les clés du 13 ^ 26. Ne pas savoir le sel me ralentirait certainement, mais je ne pense pas que cela ajouterait la tâche monumentale d'essayer de déchiffrer le chiffrement du sel en premier. C'est pourquoi je ne pense pas que ça en vaut la peine. Des pensées?

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

Answer 1

La réponse ici est de vous demander ce que vous essayez vraiment de protéger? Si une personne a accès à votre base de données, elle aura accès aux sels chiffrés et probablement également à votre code. Avec tout ce qui pourrait déchiffrer les sels cryptés? Si c'est le cas, le cryptage est de toute façon plutôt inutile. Le sel est vraiment là pour le rendre, il est donc impossible de former une table arc-en-ciel pour casser votre base de données de mot de passe en une seule fois si elle est cassé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 sera nécessaire avec vos sels ou les sels cryptés pour chaque mot de passe individuellement.

Answer 2

Cacher un sel n'est pas nécessaire.

Un sel différent doit être utilisé pour chaque hash. En pratique, il est facile d’obtenir 8 octets ou plus du générateur de nombres aléatoires de qualité cryptographique.

Extrait d'un de ma réponse précédente :

  

Salt aide à déjouer les attaques pré-calculées par dictionnaire.

     

Supposons qu'un attaquant dispose d'une liste de mots de passe probables. Il peut hacher chacun   et le comparer au hachage du mot de passe de sa victime, et voir si cela   allumettes. Si la liste est longue, cela pourrait prendre beaucoup de temps. Il ne   veut passer autant de temps sur sa prochaine cible, alors il enregistre le résultat   dans un " dictionnaire " où un hachage pointe sur l'entrée correspondante. Si   la liste des mots de passe est très longue, il peut utiliser des techniques comme un   Rainbow Table pour économiser de l’espace.

     

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

     

Donc, il n'est pas nécessaire de garder le secret sur le sel. En veillant à ce que   l'attaquant n'a pas de dictionnaire pré-calculé correspondant à celui   sel particulier est suffisant.

Après avoir réfléchi un peu plus à ce sujet, je me suis rendu compte qu'il est dangereux de se leurrer en pensant que le sel peut être caché. Il vaut bien mieux supposer que le sel ne peut pas être caché et concevoir le système de manière à ce qu'il soit sûr. Je fournis une explication plus détaillée dans un autre répondre.

Answer 3

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

Answer 4

La deuxième approche n’est que légèrement plus sûre. Les sels protègent les utilisateurs contre les attaques de dictionnaire et les attaques de table arc-en-ciel. Ils rendent plus difficile pour un attaquant ambitieux de compromettre l'ensemble de votre système, mais restent vulnérables aux attaques ciblant 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 connaissance , vous leur enregistrez une étape dans son attaque. Bien sûr, la question est sans objet si l'attaquant obtient votre base de données entière, sels et tout.

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

Answer 5

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

Pepper est une clé secrète ajoutée au mot de passe + salt qui transforme le hachage en un code d’authentification de message basé sur le hachage (HMAC). Un pirate informatique ayant accès à la sortie de hachage et au sel peut théoriquement forcer la force brute à deviner une entrée générant le hachage (et donc à valider la validation dans la zone de texte du mot de passe). En ajoutant du poivre, vous augmentez l’espace du problème de manière cryptographique et aléatoire, rendant le problème insoluble sans matériel sérieux.

Pour plus d'informations sur Pepper, consultez ici .

Voir aussi hmac .

Answer 6

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 lorsque le sel 1 est identique à sel2 Si Hash2 est remplacé par Hash1, l'utilisateur 2 peut se connecter avec le mot de passe de l'utilisateur 1

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

Answer 7

  

... 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’elle est plus sûre que la première approche, mais qu’en est-il du point de vue pratique?

D'un point de vue pratique, un sel est un détail de mise en œuvre. Si vous modifiez la manière 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 risquez de compromettre votre sécurité. Souhaitez-vous qu'un tel changement extérieur ait des problèmes de sécurité beaucoup plus profonds?

La suppression de la nécessité pour chaque compte de disposer d'un numéro de téléphone nécessite-t-elle une révision complète de la sécurité pour vous assurer que vous n'avez pas ouvert ces comptes à un compromis de sécurité?

Answer 8

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

• Le "sel" est utilisé pour que deux mots de passe égaux par ailleurs chiffrent différemment. Ainsi, un intrus ne peut pas utiliser efficacement une attaque par dictionnaire contre toute une liste de mots de passe crypté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.

Answer 9

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 essaie 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 manière à partir du PHP password_hash et password_verify . Dans mon exemple, le " coût " est 10 pour 10 bits de sel. Ou de ce qu’un autre utilisateur a dit, masqué "sel". est appelé "poivre". Le sel n'est pas crypté dans la base de données. C'est une brute forcée. Cela rendrait la table arc-en-ciel nécessaire pour inverser le hash 1000 fois plus grand. J'utilise sha256 parce que c'est rapide, mais toujours considéré comme sécurisé.

Answer 10

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

L'objectif d'un sel unique pour chaque mot de passe est d'empêcher une attaque de dictionnaire contre la base de données de mots de passe complète.

Le cryptage du sel unique pour chaque mot de passe rendrait plus difficile la résolution d'un mot de passe individuel, oui, mais vous devez vous demander s'il y a vraiment un avantage. Si l'attaquant, par force brutale, trouve que cette chaîne:

Marianne2ae85fb5d

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