Question:
Comment conserver le sel?
George
2012-07-20 11:28:12 UTC
view on stackexchange narkive permalink

Si vous prévoyez de stocker le mot de passe utilisateur en toute sécurité, vous devez au moins effectuer les opérations suivantes:

  $ pwd = hash (hash ($ password) + salt)  

Ensuite, vous stockez $ pwd dans votre système au lieu du vrai mot de passe. J'ai vu des cas où $ pwd contient le salt lui-même.

Je me demande si le sel doit être stocké séparément, ou est-ce OK si un l'attaquant obtient la valeur hachée et le sel en même temps. Pourquoi?

Eh bien, une chose à considérer avec les sels. Si vous parvenez à les garder secrets et que vos hachages de mots de passe sont divulgués, il devient complètement impossible (probablement) de récupérer un mot de passe, même avec 10000 cartes graphiques le forçant brutalement
@Earlz Ce n'est ** pas ** le but d'un sel, et il est presque impossible de garder les sels cachés de toute façon!
@Polynomial Eh bien, quelque chose à considérer. J'ai un système d'authentification qui utilise deux sels pour chaque mot de passe, un généré de manière aléatoire et stocké dans la base de données, et un qui est global sur le site Web et stocké dans le code. Mon objectif était de faire en sorte que même en cas de fuite de la base de données, il ne soit toujours pas possible de forger un cookie de connexion ou de forcer le mot de passe.
@Earlz Le deuxième sel est appelé un [poivre] (http://security.stackexchange.com/questions/3272/password-hashing-add-salt-pepper-or-is-salt-enough), qui vous protège des attaquants qui n'ont accès qu'à la base de données. C'est utile, mais puisque vous utilisez des requêtes paramétrées (vous les * utilisez *, non?) L'injection SQL n'est pas un problème, donc ce modèle d'attaquant est beaucoup moins probable.
Heh je ne savais pas qu'il y avait un nom pour ça, @Polynomial. Et je suis presque sûr que ma base de données est sécurisée, mais au cas où ce ne serait pas le cas. (MongoDB). Je pense que ça ne peut pas faire de mal et que ce n'est pas si difficile à mettre en œuvre
Pardonnez mon ignorance, mais est-il vraiment nécessaire de hacher le mot de passe _avant_ d'ajouter le sel? Si vous avez un bon algorithme de hachage, cela ne devrait pas faire de différence, non?
Qu'en est-il de $ pwd = hash (hash ($ password) + username)?
@X-Zero Il ne devrait y avoir aucune différence, et cela rend les choses plus gênantes lors de l'utilisation d'un KDF adaptatif.
@SilverViper C'est une mauvaise idée. Cela donne à un attaquant le sel, lui permettant de calculer une table arc-en-ciel à l'avance, avant de violer ouvertement votre base de données. Dans une telle situation, l'attaquant peut se connecter immédiatement après l'attaque et vous n'avez pas le temps de réagir. Voir ma réponse pour une explication plus détaillée de ce problème.
+1 pour l'utilisation de sels, ce qui est plus que ce que les grands sites Web semblent faire habituellement.
@JonasWielicki Yup. Certains stockent même en texte brut. Voir [Plaintext Offenders] (http://plaintextoffenders.com/) pour des exemples. Une autre grande entreprise, qui n'y figure pas, est Tesco.
Pourquoi stockeriez-vous un sel? Si vous pouviez le calculer en utilisant les informations d'identification d'une manière ... comme `$ salt = base64_encode ($ username. $ Password);` alors vous n'avez pas à le stocker, et si le nom d'utilisateur et le mot de passe sont corrects, ils correspondront le sel aussi.
@matejkramny C'est exactement équivalent à utiliser simplement le nom d'utilisateur comme sel, et c'est mauvais pour la même raison: si l'attaquant connaît un nom d'utilisateur dans lequel il veut s'introduire, il peut simplement précalculer les hachages pour ce nom d'utilisateur. Inclure le mot de passe dans le sel ne change rien. Pour les empêcher de précalculer les hachages, le sel doit être stocké dans la base de données, afin qu'ils ne puissent pas l'obtenir avant d'obtenir les hachages eux-mêmes, ce qui signifie qu'ils ont besoin de beaucoup de temps pour casser les hachages * après * qu'ils compromettent la base de données, ce qui vous donne la possibilité de changer les mots de passe avant qu'ils n'y aient accès.
//, Quels conteneurs utilisez-vous?Utilisez-vous iodé ou non iodé?Vous pourriez vous retrouver avec un sel empoisonné, alors évitez les contenants en métal, car le sel lessive les métaux et / ou les éléments du métal.Quoi qu'il en soit, vous n'avez pas besoin d'utiliser un économiseur de nourriture, car le sel ne rancit pas même s'il est exposé à l'air.Pour de grandes quantités, je recommande de ramasser le sel dans des sacs en plastique robustes de la taille d'un gallon.Ensuite, vous pouvez mettre les sacs dans un seau de 5 gallons de qualité alimentaire.Pour tous les preppers, il peut être utilisé comme article de troc en cas de besoin.
//, https://selfreliantschool.com/how-and-why-to-store-salt
Six réponses:
#1
+753
Polynomial
2012-07-20 19:23:55 UTC
view on stackexchange narkive permalink

TL; DR - Vous pouvez stocker le sel en texte brut sans aucune forme d'obfuscation ou de cryptage, mais ne le donnez pas seulement à quiconque le souhaite.


La raison pour laquelle nous utilisons des sels est d'arrêter les attaques de précalcul, telles que les tables arc-en-ciel. Ces attaques impliquent la création d'une base de données de hachages et de leurs textes en clair, afin que les hachages puissent être recherchés et immédiatement inversés en texte brut.

Par exemple *:

  86f7e437faa5a7fce15d1ddcb9eaeaea377667b8 ae9d71f5ee7c92d6dc9e92ffdad17b8bd49418f98 b84a516841ba77a5b4648de2cd0dfcb30ea46dbb4 c ... 948291f2d6da8e32b007d5270a0a5d094a455a02 ZZZZZX151bfc7ba4995bfa22c723ebe7921b6ddc6961bc ZZZZZY18f30f1ba4c62e2b460e693306b39a0de27d747c ZZZZZZ  

la plupart des tableaux comprennent également une liste de mots de passe communs:

  5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8 passworde38ad214943daad1d64c102faec29de4afe9da3d password1b7a875fc1ea228b9061041b7cec4bd3c52ab3ce3 letmein5cec175b165e3d5e62c9e13ce848ef6feac81bff qwerty123  

* J'utilise SHA-1 ici comme exemple, mais j'expliquerai pourquoi c'est une mauvaise idée plus tard.

Donc, si mon hachage de mot de passe est 9272d183efd235a6803f595e19616c348c275055 , il serait extrêmement facile de le rechercher dans une base de données a nd découvrez que le texte en clair est bacon4 . Donc, au lieu de passer quelques heures à déchiffrer le hachage (ok, dans ce cas, ce serait quelques minutes sur un GPU décent, mais nous en reparlerons plus tard), vous obtenez le résultat instantanément .

C'est évidemment mauvais pour la sécurité! Donc, nous utilisons un sel. Un sel est un jeton unique aléatoire stocké avec chaque mot de passe. Disons que le sel est 5aP3v * 4! 1bN<x4i&3 et le hachage est 9537340ced96de413e8534b542f38089c65edff3 . Maintenant, votre base de données de mots de passe est inutile, car personne n'a de tables arc-en-ciel qui incluent ce hachage. Il est impossible de générer des tables arc-en-ciel pour chaque sel possible.

Nous avons donc obligé les méchants à recommencer à déchiffrer les hachages. Dans ce cas, ce serait assez facile à craquer puisque j'ai utilisé un mauvais mot de passe, mais c'est quand même mieux que lui de pouvoir le rechercher en un dixième de seconde!

Maintenant, depuis le but du sel est uniquement pour empêcher la création de bases de données pré-générées, il n'a pas besoin d'être chiffré ou masqué dans la base de données. Vous pouvez le stocker en texte brut. Le but est de forcer l'attaquant à devoir casser les hachages une fois qu'il a récupéré la base de données, au lieu de pouvoir les rechercher tous dans une table arc-en-ciel.

Cependant, il y a une mise en garde. Si l'attaquant peut accéder discrètement à un salt avant de pénétrer dans votre base de données, par exemple grâce à un script qui offre le sel à quiconque le demande, il peut produire une table arc-en-ciel pour ce sel aussi facilement qu'il le pourrait s'il n'y en avait pas. Cela signifie qu'il pourrait silencieusement prendre le sel de votre compte administrateur et produire une belle grande table arc-en-ciel, puis pirater votre base de données et se connecter immédiatement en tant qu'administrateur. Cela ne vous laisse pas le temps de repérer qu'une violation a eu lieu, ni le temps de prendre des mesures pour éviter les dommages, par ex. changer le mot de passe administrateur / verrouiller les comptes privilégiés. Cela ne signifie pas que vous devez obscurcir vos sels ou tenter de les chiffrer, cela signifie simplement que vous devez concevoir votre système de telle sorte que le seul moyen d’atteindre les sels soit de pénétrer dans la base de données.

Une autre idée à considérer est un poivre. Un poivre est un second sel qui est constant entre les mots de passe individuels, mais qui n'est pas stocké dans la base de données. Nous pourrions l'implémenter en tant que H (sel + mot de passe + poivre) , ou KDF (mot de passe + poivre, sel) pour une fonction de dérivation de clé - nous en parlerons plus tard. Une telle valeur peut être stockée dans le code. Cela signifie que l'attaquant doit avoir accès à la fois à la base de données et au code source (ou aux binaires webapp dans le cas d'ASP .NET, CGI, etc.) pour tenter de casser les hachages. Cette idée ne doit être utilisée que pour compléter d’autres mesures de sécurité. Un pepper est utile lorsque vous vous inquiétez des attaques par injection SQL, où l'attaquant n'a accès qu'à la base de données, mais ce modèle devient (lentement) moins courant à mesure que les gens passent aux requêtes paramétrées. Vous utilisez des requêtes paramétrées, n'est-ce pas? Certains soutiennent qu'un poivre constitue la sécurité par l'obscurité, puisque vous ne faites qu'obscurcir le poivre, ce qui est un peu vrai, mais cela ne veut pas dire que l'idée est sans fondement.

Nous sommes maintenant dans une situation où l'attaquant peut forcer brutalement chaque hachage de mot de passe individuel, mais ne peut plus rechercher tous les hachages dans une table arc-en-ciel et récupérer immédiatement les mots de passe en clair. Alors, comment pouvons-nous empêcher les attaques par force brute maintenant?

Les cartes graphiques modernes incluent des GPU avec des centaines de cœurs. Chaque noyau est très bon en mathématiques, mais pas très bon en prise de décision. Il peut effectuer des milliards de calculs par seconde, mais c'est assez horrible pour effectuer des opérations qui nécessitent des branchements complexes. Les algorithmes de hachage cryptographique s'inscrivent dans le premier type de calcul. En tant que tels, des frameworks tels que OpenCL et CUDA peuvent être exploités afin d'accélérer massivement le fonctionnement des algorithmes de hachage. Exécutez oclHashcat avec une carte graphique décente et vous pouvez calculer un excès de 10 000 000 000 de hachages MD5 par seconde. SHA-1 n'est pas beaucoup plus lent non plus. Il y a des gens avec des plates-formes de craquage GPU dédiées contenant 6 cartes graphiques haut de gamme ou plus, ce qui entraîne un taux de craquage de plus de 50 milliards de hachages par seconde pour MD5. Permettez-moi de mettre cela en contexte: un tel système peut forcer brutalement un mot de passe alphanumérique à 8 caractères en moins de 4 minutes .

Il est clair que les hachages comme MD5 et SHA-1 sont bien trop rapides pour ce genre de situation. Une approche consiste à effectuer des milliers d'itérations d'un algorithme de hachage cryptographique:

  hash = H (H (H (H (H (H (H (H (H (H (H ( H (H (H (H (... H (mot de passe + sel) + sel) + sel) ...)  

Cela ralentit le calcul du hachage, mais n'est pas parfait . Certains préconisent l'utilisation des hachages de la famille SHA-2, mais cela n'offre pas beaucoup de sécurité supplémentaire. Une approche plus solide consiste à utiliser une fonction de dérivation de clé avec un facteur de travail. Ces fonctions prennent un mot de passe, un sel et facteur de travail. Le facteur de travail est un moyen d'adapter la vitesse de l'algorithme à vos exigences matérielles et de sécurité:

  hash = KDF (mot de passe, salt, workFactor)  

Les deux KDF les plus populaires sont PBKDF2 et bcrypt. PBKDF2 fonctionne en effectuant des itérations d'un HMAC à clé (bien qu'il puisse utiliser des chiffrements par blocs) et bcrypt fonctionne en calculant et en combinant un grand nombre de blocs de texte chiffré à partir du chiffrement par blocs Blowfish. Les deux font à peu près le même travail. Une nouvelle variante de bcrypt appelée scrypt fonctionne sur le même principe, mais introduit une opération de mémoire qui rend le cracking sur les GPU et les FPGA -farms complètement impossible, en raison de la bande passante mémoire restrictions.


Mise à jour: Depuis janvier 2017, l'algorithme de hachage de pointe de choix est Argon2, qui a gagné le concours de hachage de mots de passe.


J'espère que cela vous donnera un bon aperçu des problèmes auxquels nous sommes confrontés lors du stockage des mots de passe, et répond à votre question sur le stockage du sel. Je recommande vivement de consulter les "liens d'intérêt" au bas de la réponse de Jacco pour en savoir plus, ainsi que les liens suivants:

+1, Amen. Je souhaite que nous puissions créer un index / répertoire qui pointe vers les bonnes réponses aux questions courantes / populaires telles que celle-ci. D'autant plus que les questions courantes / populaires attirent régulièrement des réponses assez peu sûres.
Je lisais l'autre jour sur [Scrypt] (http://en.wikipedia.org/wiki/Scrypt), qui est un KDF qui vise à être plus coûteux en calcul que Bcrypt et PBKDF2. Cela peut être une autre option à considérer.
@GarrettAlbright J'ai mentionné scrypt dans l'avant-dernier paragraphe. Le seul inconvénient de Scrypt est qu'il n'y a pas autant de bibliothèques disponibles et qu'il n'y a pas eu beaucoup d'études à ce sujet. Pour le moment, je suggère bcrypt, car les moteurs de craquage basés sur FPGA ne sont pas un problème de sécurité pour la plupart des gens, mais lorsque scrypt a été soigneusement étudié par quelques cryptographes, je serais heureux de dire aux gens de l'utiliser à la place.
Also have a look at https://wiki.mozilla.org/Identity/CryptoIdeas/01-PBKDF-scrypt
@Polynomial peut-être également ajouter un lien vers http://stackoverflow.com/questions/1645161/salt-generation-and-open-source-software/1645190#1645190?
+1 pour créer un lien vers la section ** Liens d'intérêt ** de la réponse @Jacco's.
Cependant, si vous implémentez des facteurs tels que le code SMS, vous pouvez même stocker vos mots de passe en texte clair ... car ils doivent toujours passer par le code SMS.
@matejkramny Non. Le principal problème est que les utilisateurs réutiliseront TOUJOURS leurs mots de passe pour d'autres sites. Vous avez le devoir de protéger les mots de passe qui vous sont donnés.
Quelle est la raison de toujours ajouter à nouveau le sel lors du hachage du mot de passe?
@cooky451 Je ne suis pas sûr de ce que vous demandez, mais je suggère de créer une nouvelle question.
bcrypt s'avère également être le plus simple à utiliser du point de vue d'un programmeur. Vous n'avez même pas besoin de trouver un sel vous-même car la bibliothèque cryptographique le fera pour vous, puisque la sortie inclut le sel (c'est sous la forme `$ $ $ `). Ainsi, toutes les informations nécessaires sont stockées dans ce que vous pouvez appeler le hachage. Cela ne devient pas plus simple (tout en étant hautement sécurisé).
Juste pour souligner: assurez-vous d'utiliser un sel *** différent *** pour chaque mot de passe!Si vous utilisez le même sel pour chaque mot de passe, la complexité de calcul de l'algorithme de force brute est considérablement réduite.De plus, un attaquant pourrait voir quels utilisateurs utilisent le même mot de passe simplement en comparant les hachages, ce qui pourrait avoir un effet de désanonymat sur les utilisateurs qui réutilisent les mots de passe sur plusieurs comptes.
Bouncycastle a une implémentation scrypt.
Vraiment bonne réponse.Mais vous n'avez toujours pas répondu à la question «où dois-je stocker le sel aléatoire»?Vous avez besoin de ce sel aléatoire pour vérifier si le mot de passe entré est correct ... est-ce que je me trompe?
"Cela signifie que l'attaquant doit avoir accès à la fois à la base de données et au code source" - ce n'est pas vrai pour cette dernière partie.Dans de nombreux cas (sinon la plupart), les chaînes ne sont pas chiffrées.Un hacker peut facilement charger un exécutable dans un éditeur hexadécimal et voir la plupart des chaînes.Ils peuvent également parcourir le code d'assemblage pour lire les valeurs.Dans de nombreux cas, le code source n'est pas requis, et donc toute valeur de sel et de poivre stockée / calculée du côté client (c'est-à-dire l'application de bureau) n'est pas impossible;juste dur.;) Ne les stockez pas en texte brut.Masquez ces types de chaînes pour rendre la recherche plus difficile.
@JamesWilkins Oui, je pensais aux applications web PHP / Python quand j'ai écrit ceci.Je vais modifier pour refléter le cas plus diversifié où l'application Web est un binaire .NET ou CGI.
–1 - trop de texte, et ne répond pas réellement à la question sur l'endroit où stocker le sel (même si j'ai arrêté de lire à mi-chemin car le texte n'était pas pertinent par rapport à la question réelle)
#2
+82
Jacco
2012-07-20 12:37:05 UTC
view on stackexchange narkive permalink

Un sel n'est pas censé être secret, à la place, un sel «fonctionne» en s'assurant que le résultat de hachage est unique pour chaque instance utilisée. Ceci est fait en choisissant une valeur de sel aléatoire différente pour chaque hachage calculé.

L'intention du sel n'est pas compromise lorsqu'elle est connue; l'attaquant doit toujours attaquer chaque hachage séparément. Par conséquent, vous pouvez simplement stocker le sel à côté du mot de passe haché.

Liens d'intérêt :
Comment hacher les mots de passe en toute sécurité?
Le hachage de mot de passe ajoute du sel et du poivre ou le sel suffit-il?
Salt Generation et logiciel open source

Gardez à l'esprit que si le sel fuit (par exemple à travers une faille dans votre code), l'attaquant peut créer une table arc-en-ciel pour ce sel à l'avance. Cela rend difficile pour vous de prendre des mesures préventives si quelqu'un vole vos hachages plus tard, car ils peuvent immédiatement déchiffrer le mot de passe (ils ont déjà la table arc-en-ciel!) Et accéder au compte.
@Polynomial Vous avez soulevé un très bon point. Peut-être aimeriez-vous écrire une réponse qui couvre ce que vous avez déclaré? Je l'apprécierais certainement, et c'est beaucoup plus facile à lire de cette façon.
@Terry Chia: La prépension est plus courante.
À côté du * mot de passe haché, salé *.
@Polynomial où stockez-vous alors le sel?Il semble que si l'attaquant trouve le sel, il peut pénétrer dans la base de données?
#3
+38
lxgr
2012-07-20 12:38:24 UTC
view on stackexchange narkive permalink

Le sel peut et doit être stocké juste à côté du mot de passe salé et haché. De plus, le sel doit être unique par mot de passe.

Son but est de rendre impossible l'attaque d'une base de données de mots de passe divulguée en utilisant des tables précalculées de paires de mots de passe-hachage.

Cela fonctionne parce que le sel n'est connu de l'attaquant que dès qu'il obtient les mots de passe réels (durcis); rendant ainsi impossible toute attaque précalculée. (Si vous n'utilisez pas un sel unique par mot de passe, mais un sel global, des tables précalculées peuvent encore être utilisées - bien qu'elles devraient être précalculées spécifiquement pour le sel de votre application.)

Lorsque vous stockez le sel ailleurs que juste à côté du mot de passe, vous pouvez gagner une sécurité supplémentaire, mais cela va presque à l'encontre de l'objectif: chaque fois que vous voulez valider un mot de passe, vous avez besoin à la fois du sel et du mot de passe haché, ils doivent donc être très "proches" (dans un sens arichtectural) de toute façon.

#4
+14
Tgr
2012-07-20 22:35:16 UTC
view on stackexchange narkive permalink

Stocker vos sels séparément offre une sécurité supplémentaire, mais pas beaucoup - après tout, la base de données devrait être le meilleur endroit protégé de l'application, donc si l'attaquant a accès à la base de données, il y a de fortes chances qu'il ait accès à d'autres données . D'un autre côté, vous avez besoin d'un sel différent pour chaque utilisateur, ce qui signifie que vous avez besoin de beaucoup de sel - il n'est tout simplement pas possible de le stocker en dehors de la base de données.

Il existe une pratique consistant à utiliser un second morceau de sel (parfois appelé poivre) qui est le même pour tous les utilisateurs, et le stocker en dehors de la base de données (peut-être dans une variable d'environnement, ou une sorte de fichier de configuration), de sorte que l'attaquant n'y accède pas avec un simple SQL injection. Cela ajoute un peu de sécurité, mais comme indiqué ci-dessus, n'en attendez pas trop et utilisez bcrypt ou une autre méthode de hachage lente pour vous défendre contre les sels volés.

#5
+5
user7610
2012-07-20 20:58:26 UTC
view on stackexchange narkive permalink

Je voudrais attirer votre attention sur un article intéressant à ce sujet du titre Stocker les mots de passe en toute sécurité

TL; DR

L'auteur de l'article explique le salage et le poivre. En outre, il / elle fait valoir qu'en fait, vous ne souhaitez pas utiliser une fonction de hachage cryptographique pour stocker les mots de passe. Les deux caractéristiques principales d'un hachage sont que

  1. il doit être unidirectionnel et.
  2. il devrait être bon marché à calculer.

De toute évidence, ces exigences sont opposées. Un compromis est donc fait. Vous ne voulez pas que l'attaquant puisse calculer ses tentatives de force brute à moindre coût. Par conséquent, pour une meilleure sécurité, vous avez réellement besoin d'une fonction de dérivation de clé, quelque chose qui est à sens unique et qui prend plus de temps à calculer (par exemple 0,1 s).

Il existe des schémas / implémentations pour faire cela, ce que l'on appelle les fonctions de dérivation de clé adaptative qui sont bien étudiées et jugées sûres (l'auteur en nomme trois: PBKDF2, bcrypt, scrypt )

À ce stade, votre réponse n'a vraiment rien apporté à la table, vous devriez donc probablement avoir juste lié l'article dans un commentaire. C'est un bel article cependant - très complet et couvre toutes les bases. Je garderai un signet pour référence future!
Bel article! Autant que je sache, PBKDF2 est une fonction de dérivation de clé adaptative, mais BCrypt et SCrypt ne le sont pas; ce sont des algorithmes de hachage de coûts adaptatifs. (La différence est subtile, mais réelle).
Polynôme: Vous avez raison. J'avais tellement hâte de publier l'article (je l'avais dans mes signets et j'étais excité que son heure vienne enfin) que j'ai parcouru votre réponse et j'ai complètement raté le dernier paragraphe. Pardon
#6
-6
Andrew Smith
2012-07-21 00:41:49 UTC
view on stackexchange narkive permalink

Eh bien, vous séparez le hachage du sel dans deux cases différentes - j'espère que vous comprenez la bonne réponse. Et assurez-vous d'avoir la même quantité des deux, comme le sel 256 bits, le hachage 256 bits, vous pouvez augmenter la sécurité si vous utilisez un simple serveur de sel isolé.

Pourquoi stocker le hasch et le sel à différents endroits?
Voir par exemple http://security.stackexchange.com/a/17449/5501
-1 'un hash 256bit' ne vous achète rien de poids ici. L'algorithme doit être lent. Séparer le hasch et le sel dans différentes boîtes crée une toute nouvelle gamme de problèmes, il suffit de s'en tenir aux meilleures pratiques.


Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...