Où stockez-vous vos cordes de sel?

250

J'ai toujours utilisé une chaîne de sel par entrée appropriée lors du hachage des mots de passe pour le stockage de la base de données. Pour mes besoins, le stockage du sel dans la base de données à côté du mot de passe haché a toujours bien fonctionné.

Cependant, certaines personnes recommandent que le sel soit stocké séparément de la base de données. Leur argument est que si la base de données est compromise, un attaquant peut toujours construire une table arc-en-ciel en tenant compte d'une chaîne de sel particulière afin de casser un compte à la fois. Si ce compte a des privilèges d'administrateur, il n'a peut-être même pas besoin d'en casser d'autres.

Du point de vue de la sécurité, vaut-il la peine de stocker les sels dans un endroit différent? Considérez une application Web avec le code serveur et la base de données sur la même machine. Si les sels sont stockés dans un fichier plat sur cette machine, il est probable que si la base de données est compromise, le fichier de sels le sera également.

Existe-t-il des solutions recommandées à cela?

— friedo
source

9

S'il y a un endroit où vous pouvez stocker le sel auquel l'attaquant ne peut pas accéder, vous devez également y stocker les mots de passe. Mais pourquoi ne pas utiliser un sel différent pour chaque mot de passe?

— jrockway

8

Il utilise un sel différent pour chaque mot de passe, jrockway.

— Amber

9

Quelle est la taille de vos sels? Vos sels doivent être suffisamment gros (32 bits?) Pour qu'il n'y ait pratiquement aucune chance qu'une table arc-en-ciel ait été précalculée pour cela.

— M. Dudley

@emddudley ces jours-ci, j'ai l'habitude d'utiliser un entier 64 bits comme sel, mais il n'y a aucune raison pour que je ne puisse pas les allonger.

— friedo

10

Auteur de PWDTK ici sourceforge.net/projects/pwdtknet , honnêtement, je ne m'inquiéterais pas et je stockerais simplement du sel dans la même base de données que le mot de passe. Vous devez toujours supposer que le sel est connu d'un attaquant de toute façon, vous devez donc vous concentrer sur l'utilisation d'un sel LARGE CRYPTO-RANDOM et effectuer suffisamment d'étirement des touches (itérations dans PBKDF2) de sorte qu'il ne soit pas possible de créer une seule table arc-en-ciel pour un sel connu. Honnêtement, ce que vous essayez de réaliser en mettant le sel ailleurs est «la sécurité par l'obscurité» et ne sert généralement aucun avantage lorsque vous regardez des choses comme un autre serveur qui peut potentiellement tomber en panne.

— thashiznets

259

Le but des tables arc-en-ciel est qu'elles sont créées à l'avance et distribuées en masse pour gagner du temps de calcul pour les autres - il faut autant de temps pour générer des tables arc-en-ciel à la volée que pour casser directement la combinaison mot de passe + sel (car efficacement ce qui est fait lors de la génération de tables arc-en-ciel pré-exécute les calculs de forçage brutal du hachage), ainsi l'argument selon lequel en connaissant le sel quelqu'un pourrait "générer une table arc-en-ciel" est faux.

Il n'y a aucun intérêt à stocker des sels dans un fichier séparé tant qu'ils sont par utilisateur - le but du sel est simplement de faire en sorte qu'une table arc-en-ciel ne puisse pas casser tous les mots de passe de la base de données.

— ambre
source

17

D'accord. Le modèle de menace contre lequel vous vous protégez en stockant le sel séparément est un utilisateur qui peut en quelque sorte accéder au sel dans la base de données par des moyens néfastes, mais pas le hachage (dans la base de données). Et que cette personne commencera à calculer une table arc-en-ciel à l'avance, en supposant qu'elle sera capable de trouver le hachage plus tard. Pas impossible, mais cela ne vaut pas non plus l'effort d'ingénierie pour se défendre contre cette seule avenue d'attaque.

— Tom Ritter

Joli post, je me demandais la même chose. Je n'ai jamais pensé à un sel par utilisateur, je pensais qu'un seul sel fonctionnerait pour tous les utilisateurs. Qu'en est-il d'un sel stocké en tant que fichier XML chargé par App Server? ou peut-être codé en dur dans une servlet?

— jigzat

9

@Jigzat - Le salage est inutile si vous n'avez pas de sel séparé pour chaque utilisateur. Le point de sels est de faire de la rupture des hachages une tâche distincte pour chaque mot de passe utilisateur; si le sel est le même pour tous, ce n'est pas le cas.

— Amber

3

@TomRitter ce n'est pas le seul cas. vous supposez que tous les mots de passe sont compliqués. certains attaquants peuvent prendre le sel et le hachage et ne vérifier que les 10 000 mots de passe les plus courants. de cette façon, ils obtiendront un nombre décent de personnes. si, cependant, ils n'ont pas accès au sel, c'est comme si l'utilisateur avait un mot de passe plus sûr et plus long. maintenant, il est probable que la base de données de sel restera en sécurité pendant le vol de la base de données de mots de passe, mais c'est un problème distinct.

— chacham15

@Amber, je crois que TomRitter a raison. Stocker le sel séparément signifie la différence entre forcer un attaquant à utiliser une attaque par force brute et une attaque par dictionnaire plus facile. Si vous connaissez le sel, vous pouvez simplement l'ajouter lors d'une exécution de l'attaque du dictionnaire du moulin. Si vous pouvez défendre à 100% votre sel, vous pouvez simplement utiliser le même sel et forcer les attaquants à tout forcer (même pour les utilisateurs qui utilisent "mot de passe" comme mot de passe). Mais pouvez-vous défendre votre sel ... probablement pas. Il pourrait donc aussi bien réduire les points de défaillance en le stockant à côté du hachage et appliquer des règles de mot de passe plus strictes.

— Ultratrunks

35

Je fournirai une interprétation légèrement différente à ce sujet.

Je stocke toujours le sel mélangé avec le hachage du mot de passe salé.

Par exemple, je placerai la première moitié du sel avant le hachage salé du mot de passe, et la dernière moitié du sel après le hachage salé du mot de passe. L'application est consciente de cette conception et peut donc récupérer ces données et obtenir le hachage de sel et de mot de passe salé.

Ma justification de cette approche:

Si les données de mot de passe / de hachage sont compromises et tombent entre les mains d'un attaquant, l'attaquant ne saura pas ce qu'est le sel en regardant les données. De cette façon, un attaquant ne peut pratiquement pas effectuer une attaque par force brute pour obtenir un mot de passe correspondant au hachage, car il ne connaît pas le hachage pour commencer et n'a aucun moyen de savoir quelles parties des données sont des parties du sel, ou parties du hachage de mot de passe salé ( sauf s'il connaît la logique d'authentification de votre application ).

Si le hachage de mot de passe salé est stocké tel quel, une attaque par force brute peut être effectuée pour obtenir un mot de passe qui, lorsqu'il est salé et haché, produit les mêmes données que le hachage de mot de passe salé.

Cependant, par exemple, même si le hachage du mot de passe salé a été stocké tel quel, mais pré-suspendu avec un seul octet aléatoire, tant que l'attaquant ne sait pas que ce premier octet doit être rejeté, cela augmenterait également la difficulté d'attaque. Votre application devrait ignorer le premier octet des données lorsqu'elle est utilisée pour authentifier votre utilisateur.

La conclusion à cela ..

1) Ne stockez jamais les données que votre application d'authentification utilise sous leur forme exacte.

2) Si possible, gardez votre logique d'authentification secrète pour plus de sécurité.

Allez plus loin ..

Si vous ne pouvez pas garder secret la logique d'authentification de votre application - beaucoup de gens savent comment vos données sont stockées dans la base de données. Et supposez que vous avez décidé de stocker le hachage de mot de passe salé mélangé avec le sel, avec une partie du sel précédant le hachage de mot de passe salé et le reste du sel l'ajoutant.

Lors de la génération du sel aléatoire, vous pouvez également décider de manière aléatoire quelle proportion de votre sel vous stockerez avant / après le hachage du mot de passe salé.

Par exemple, vous générez un sel aléatoire de 512 octets. Vous ajoutez le sel à votre mot de passe et obtenez le hachage SHA-512 de votre mot de passe salé. Vous générez également un entier aléatoire 200. Vous stockez ensuite les 200 premiers octets du sel, suivis du hachage du mot de passe salé, suivi du reste du sel.

Lors de l'authentification de la saisie du mot de passe d'un utilisateur, votre application passera sur la chaîne et supposera que le premier 1 octet des données est le premier 1 octet du sel, suivi du hachage salé. Cette passe échouera. L'application continuera en utilisant les 2 premiers octets des données comme les 2 premiers octets du sel et répétera jusqu'à ce qu'un résultat positif soit trouvé après avoir utilisé les 200 premiers octets comme les 200 premiers octets du sel. Si le mot de passe est incorrect, l'application continuera d'essayer toutes les permutations jusqu'à ce qu'aucune ne soit trouvée.

Les avantages de cette approche:

Sécurité accrue - même si votre logique d'authentification est connue, la logique exacte est inconnue au moment de la compilation. Il est pratiquement impossible d'effectuer une attaque par force brute, même en connaissant la logique exacte. Des longueurs de sel accrues augmenteront encore la sécurité.

Les inconvénients de cette approche:

Étant donné que la logique exacte est déduite au moment de l'exécution, cette approche est très gourmande en ressources processeur. Plus la longueur du sel est longue, plus cette approche est gourmande en CPU.

L'authentification de mots de passe incorrects entraînera le coût le plus élevé du processeur. Cela peut être contre-productif pour les demandes légitimes, mais augmente la sécurité contre les attaquants.

Cette approche peut être mise en œuvre de différentes manières et peut être rendue encore plus sûre en utilisant des sels de largeur variable et / ou des hachages de mots de passe salés.

— Ibraheem
source

9

Avec votre approche, vous ajoutez simplement un secret à votre processus de hachage (l'algorithme qui applique le sel). Ce secret que vous pouvez ajouter beaucoup plus facilement avec l'ajout d'un poivre en plus du sel, j'ai essayé de le souligner dans mon tutoriel . Les fonctions de hachage modernes comme BCrypt appliqueront le sel de leur propre chef, en utilisant le sel d'origine à chaque itération, vous n'auriez donc aucun contrôle sur cela.

— martinstoeckli

@martinstoeckli Bien que vous ayez raison de dire que BCrypt applique le sel par lui-même, le stockage de ce sel + hachage est à vous en tant que développeur. Ainsi, vous pouvez facilement ajouter un poivre au sel + hachage et le conserver dans la base de données. Ensuite, lors de la récupération ultérieure, vous lisez la valeur de la base de données, supprimez la valeur du piment et transmettez la valeur restante à BCrypt.

— PeterToTheThird

2

@PeterToTheThird - Cela annulerait l'avantage du poivre. Le poivre ajoute un secret côté serveur et ne fonctionne que tant qu'il reste secret (en face du sel). Une attaque typique est l'injection SQL, lorsque quelqu'un accède à la base de données mais pas au code, un piment stocké dans la base de données sera alors inutile. La plupart des implémentations BCrypt ajoutent automatiquement le sel à la valeur de hachage résultante, donc cette valeur contient déjà le sel, le facteur de coût, l'algorithme et le hachage. Cette chaîne peut être stockée dans un seul champ de 60 caractères.

— martinstoeckli

De plus, lorsque vous utilisez une fonction de "renforcement des clés" telle que BCrypt, vous n'avez aucun contrôle sur l'utilisation du sel. Cependant, si vous souhaitez utiliser un poivre, vous devez simplement ajouter le poivre au sel et l'utiliser comme «sel poivré» à la place de l'entrée «sel» de la fonction de hachage. Le «poivre» est alors une donnée appropriée qui n'est pas stockée dans la base de données, mais intégrée dans le code d'authentification, ou stockée dans un autre emplacement sécurisé. J'ai abordé le problème dans une perspective générique, en utilisant SHA-512 comme exemple de fonction, mais BCrypt etc. peut également être utilisé de manière similaire.

— Ibraheem

2

@martinstoeckli - oui, l'implémentation réelle dépend de la fonction de hachage que vous utilisez. Évidemment, vous devez prendre en compte les paramètres et les sorties de la fonction de hachage lors de la mise en œuvre de votre logique d'authentification. En fin de compte, un poivre n'est qu'une autre variable introduite dans votre fonction de hachage, qui n'est pas stockée au même endroit que le sel et le hachage.

— Ibraheem

23

Souvent, ils sont ajoutés au hachage et stockés dans le même champ.

Il n'est pas nécessaire de les stocker séparément - le point est d'utiliser un sel aléatoire pour chaque mot de passe afin qu'une seule table arc-en-ciel ne puisse pas être utilisée contre l'ensemble de vos hachages de mot de passe. Avec des sels aléatoires, un attaquant doit forcer chaque hachage séparément (ou calculer une table arc-en-ciel pour tous les sels possibles - beaucoup plus de travail).

Si vous aviez un emplacement de stockage plus sécurisé, il serait logique de simplement y stocker les hachages.

— personne
source

4

Mais que se passe-t-il si tous les mots de passe hachés sont divulgués, y compris leur sel correspondant? N'est-ce pas tout aussi précaire?

— mghaoui

10

@mghaoui Mais alors, si vous vouliez connaître le "mot de passe", il vous faudrait tout de même construire une table arc-en-ciel pour chaque sel, à moins que certains sels ne soient identiques.

— Franklin

4

Basé sur le livre Developing ASP.NET MVC 4 Web Applications de William Penberthy:

Pour accéder aux sels stockés dans une base de données distincte, les pirates informatiques doivent pirater deux bases de données différentes pour accéder au sel et au mot de passe salé. Les stocker dans la même table que le mot de passe, ou même une autre table de la même base de données, signifierait que lorsque les pirates auront accès à la base de données, ils auront accès à la fois au sel et au hachage du mot de passe. Étant donné que la sécurité comprend le processus de piratage du système trop coûteux ou trop long pour en valoir la peine, doubler la quantité d'accès qu'un pirate informatique devrait obtenir devrait rendre le système plus sûr.
La facilité d'utilisation est la principale raison de conserver les sels dans la même base de données que les mots de passe hachés. Vous n'auriez pas à vous assurer que deux bases de données sont toujours disponibles en même temps et toujours synchronisées. L'avantage d'avoir un sel est minime si chaque utilisateur a un sel aléatoire car bien que cela puisse faciliter la découverte du mot de passe d'un individu, la quantité de force nécessaire pour casser les mots de passe du système dans son ensemble sera élevée. Dans ce niveau de discussion, c'est vraiment ce que l'on attend: protéger les mots de passe. Si les pirates ont acquis une copie de la base de données, les données de votre application sont déjà compromises. À ce stade, le problème consiste à atténuer les risques pour les utilisateurs en raison du potentiel des mots de passe partagés.
L'obligation de maintenir deux bases de données liées distinctes est très importante. Certes, il ajoute la perception de la sécurité, mais le seul avantage qu'il donne est qu'il protège un mot de passe, un seul élément de données. Si chaque champ de la base de données était chiffré individuellement et que ce même sel était utilisé pour cela, il serait plus judicieux de le stocker séparément des données car la sécurité de base de votre système est améliorée.

— DaNeSh
source

Si l'application peut s'authentifier auprès des deux bases de données, n'est-ce pas essentiellement la même chose que s'il s'agissait d'une seule base de données, si l'attaquant a compromis le code de l'application?

— John Ernest

0

L'utilité d'un sel est de rendre toutes les tables arc-en-ciel inutiles et d'exiger un nouvel ensemble d'entre elles. Il faut autant de temps pour deviner une chaîne que pour faire une table arc-en-ciel. Par exemple, le hachage SHA-256 de "mot de passe" est 5e88 4898 da28 0471 51d0 e56f 8dc6 2927 7360 3d0d 6aab bdd6 2a11 ef72 1d15 42d8. Après l'ajout d'un sel, tel que "badpassword", la nouvelle chaîne à hacher est "passwordbadpassword" qui, en raison de l'effet d'avalanche, modifie considérablement la sortie, en457b f8b5 37f1 802e f9c8 2e46 b8d3 f8b5 721b 7cbb d485 f0bb e523 bfbe 73e6 58d6 .

Normalement, le sel est simplement stocké dans la même base de données que le mot de passe, également parce que si une base de données est piratée, il est probable que l'autre le soit également.

— Eric Jin
source