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


99

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


Bonne question, Kevin, très opportune. Je ne peux pas faire de commentaire sur la sécurité, mais il y a un coup de performance pour tout ce cryptage et décryptage, c'est sûr.
DOK

Vous n'avez pas besoin d'ignorer la table arc-en-ciel de taille décente - cette table rend également le sel crypté inutile car il peut décrypter le hachage salé et être utilisé à nouveau pour décrypter le hachage d'origine. La bonne nouvelle est qu'il faudrait probablement des siècles pour créer une table.
tloach

Ce qui me fait comprendre, c'est que je ne suis pas tout à fait certain qu'une table arc-en-ciel de cette taille prendrait autant de temps à créer. C'est une idée farfelue, prenez une plate-forme informatique distribuée comme Kraken (vraiment c'est un peu ce que c'est) pour la générer. Combien de temps cela prendrait-il alors?
kemiller2002

3
@Kevin: SHA1 renvoie une chaîne hexadécimale de 40 caractères, il y a donc 40 ^ 16 valeurs de retour possibles. En supposant qu'un seul ordinateur puisse calculer 1000 hachages par seconde, je calcule que 1 000 000 d'ordinateurs prendraient environ 10 milliards d'années pour générer une table arc-en-ciel capable de déterminer une chaîne de cette taille.
tloach

+1 bonne question et vous êtes bien lu. Je pense que vous avez eu la mauvaise réponse à cette question. Le doit toujours être un secret car le hachage ne peut pas être cassé tant qu'il n'est pas obtenu. Vous devriez lire à propos de CWE-760 ( cwe.mitre.org/data/definitions/760.html )
rook

Réponses:


45

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.


Un peu nouveau dans ces concepts. Donc, cela peut ressembler à une question naïve, mais ne serait-il pas plus facile de former cette table arc-en-ciel en connaissant le sel pour chaque mot de passe, car vous essaieriez une seule combinaison pour la valeur de sel pour chaque mot de passe possible?
stdout

La table ranbow de disons 1000 mots de passe couramment utilisés casserait cela presque à la même vitesse que le simple hachage. La seule façon dont cela fonctionnerait est que si vous supposez que la distribution de vos mots de passe est uniforme .. et nous savons qu'ils ne le sont pas
DérnFoRCe

100

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.


1
Cacher le sel est nécessaire car le hachage ne peut pas être cassé tant qu'il n'est pas obtenu. Ceci est lié à CWE-760 ( cwe.mitre.org/data/definitions/760.html )
tour

28
@The Rook - Non, vous interprétez mal ce problème. Il fait référence à l'utilisation de sels prévisibles. Il ne dit rien sur le fait de garder le sel secret. En effet, vous ne pouvez pas vraiment garder le secret du sel sans utiliser un autre secret ... auquel cas, pourquoi n'utiliseriez-vous pas le deuxième secret comme sel? Utiliser le nom d'utilisateur comme sel est mauvais car il est probable que plusieurs systèmes partagent le même nom d'utilisateur, ce qui rend plus intéressant de créer une table pour ce sel particulier. Les sels aléatoires sont les meilleurs, mais ils n'ont pas besoin d'être tenus secrets.
erickson


1
@erickson, je pense que vous mélangez la terminologie ici. Les sels ne contrarient pas les attaques par dictionnaire à moins qu'ils ne soient cachés. Beaucoup de sels sont stockés ouvertement. Et si vous connaissez le sel, votre attaque par dictionnaire n'est ralentie que par le temps qu'il faut pour ajouter le sel à votre terme de dictionnaire :) Les sels empêchent les recherches dans les tables Rainbow ... qui sont sacrément rapides. Si l'attaquant connaît votre sel, vous n'êtes pas protégé contre une attaque par dictionnaire. Si l'attaquant ne connaît pas votre sel, vous êtes protégé contre une attaque par dictionnaire et il doit utiliser une attaque par force brute.
Ultratrunks

4
@Ultratrunks Oui, j'ai clarifié certaines de mes réponses sur ce sujet, en utilisant le terme «attaques de dictionnaire précalculées». Plus général que les tables Rainbow, il fait référence à toute structure qui permet une recherche inversée d'un texte brut en utilisant son hachage comme clé. Quels que soient les termes que vous choisissez, mon explique explicitement que le sel est destiné à vaincre les tables Rainbow et les mécanismes similaires. Vous devez toujours supposer que l'attaquant connaît le sel. S'il était possible de le garder secret, vous n'auriez pas besoin de hacher le mot de passe.
erickson

3

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.


3

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.


Comment se protègent-ils contre les attaques par dictionnaire?
tloach

En forçant l'attaquant à créer un nouveau dictionnaire pour chaque combinaison mot de passe + sel. Sans sel, un dictionnaire peut être utilisé pour l'ensemble de votre table de mots de passe.
Bill le lézard

"Bien sûr, la question est sans objet si l'attaquant obtient toute votre base de données, les sels et tout." N'est-ce pas pour cela que le sel est crypté?
Patrick McElhaney

1
@Bill: Vous venez de décrire une table arc-en-ciel. Une attaque par dictionnaire est l'endroit où je prends des mots normaux et tente de m'authentifier avec eux. C'est une force brute avec un espace de réponse considérablement réduit. Aucun hash ne se défend contre la force brute.
tloach

Je n'ai jamais entendu parler de cette pratique, mais je ne suis pas un expert en sécurité. Il semble que le cryptage de sels uniques ajouterait une couche supplémentaire de protection contre les attaques de table arc-en-ciel.
Bill the Lizard

3

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


2
Sans oublier si vous utilisez des informations utilisateur arbitraires, quand ils modifient ces informations, vous devez les saisir à nouveau pour pouvoir le crypter à nouveau avec le nouveau sel.
Treborbob

3

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 .


2

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.


Nous n'utilisons pas le même hachage pour chaque compte, nous utilisons le même type d'informations pour chaque hachage. Par exemple, le sel d'un compte est le numéro de téléphone du compte, etc.
kemiller2002

Je sais que c'est longtemps plus tard, mais ... vous ne pouvez pas compter sur les sels pour vous protéger contre ce type d'attaque. Nous devons supposer qu'un attaquant sait tout sur le système d'authentification autre que le secret (c'est-à-dire le mot de passe). Par conséquent, nous devons supposer que l'attaquant sait a) ce que nous utilisons comme sel (la plupart du temps, il est stocké dans la même base de données et la même table en texte clair) et b) comment nous hachons avec le sel (c'est-à-dire ajouter, hacher deux fois, etc). Si l'utilisateur a la possibilité de changer les hachages, nous devons supposer qu'il peut également changer le sel. Les sels n'aideront pas ici.
Dave Satch

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.


0

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


Donc, si mon mot de passe est "345678" et que le sel aléatoire que vous ajoutez se trouve être, disons, "12". Si quelqu'un entre "45678" comme mot de passe. Cela semble faux à bien des égards.
Yurippenet

-1

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?


2
Si quelqu'un force un mot de passe si impossible à deviner, je dirais que vous êtes de toute façon arrosé, car apparemment, ils ont une technologie à laquelle personne n'a même pensé.
Instance Hunter
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.