Salt Generation et logiciel open source

Question

Si je comprends bien, la meilleure pratique pour générer des sels est d'utiliser une énigmatique formule (ou même la magie de la constante) stockés dans votre code source.

Je suis en train de travailler sur un projet que nous prévoyons sur la libération de l'open source, mais le problème est que la source est la formule secrète pour générer des sels, et donc la possibilité d'exécuter un arc-en-ciel de la table des attaques sur notre site.

Je suppose que beaucoup de gens ont envisagé ce problème avant moi, et je me demandais quelle est la meilleure pratique est. Il me semble qu'il n'y a pas de point d'avoir du sel si le code est open source, parce que les sels peuvent être facilement démonté.

Pensées?

Answer 1

Depuis des questions sur le salage des hachages de venir sur un assez régulièrement et il semble être tout à fait un peu de confusion sur le sujet, j'ai étendu cette réponse.

Qu'est ce qu'un sel?

Un sel est un hasard ensemble d'octets de longueur fixe qui est ajouté à l'entrée d'un algorithme de hachage.

Pourquoi est-salage (ou semis) un hachage utile?

L'ajout d'un hasard de sel à une table de hachage garantit que le même mot de passe va produire beaucoup de différentes tables de hachage. Le sel est généralement stocké dans la base de données, ainsi que le résultat de la fonction de hachage. Saler un hachage est bon pour un certain nombre de raisons:

1. Saler augmente la difficulté et le coût de l'precomputated attaques (y compris les rainbow tables)
2. Le salage permet de s'assurer que le même mot de passe n'est pas le même hachage. Cela permet de s'assurer que vous ne peut pas déterminer si deux utilisateurs ont le même mot de passe. Et, plus important encore, vous ne pouvez pas déterminer si la personne utilise le même mot de passe sur les différents systèmes.
3. Saler augmente la complexité des mots de passe, augmentant ainsi considérablement la diminution de l'efficacité à la fois un Dictionnaire et d'Anniversaire des attaques. (Ceci n'est vrai que si le sel est entreposés à l'écart de la table de hachage).
4. Bon salage grandement augmente l'espace de stockage nécessaire pour le précalcul des attaques, jusqu'au point où ils ne sont plus pratique. (8 caractères sensibles à la casse alpha-numérique des mots de passe avec 16 bits de sel, de hachage de 128 bits, prendre un peu moins de 200 exaoctets sans arc-en-ciel de réduction).

Il n'est pas nécessaire pour le sel à être secret.

Un sel n'est pas une clé secrète, au lieu d'un sel "œuvres" en faisant de la fonction de hachage spécifiques à chaque instance. Salé de hachage, il n'y a pas une fonction de hachage, mais pour tout le sel de la valeur. Cela empêche l'attaquant de s'attaquer à la N des mots de passe hachés pour les moins de N fois le coût d'attaquer un mot de passe. C'est le point de la le sel.
Un "secret de sel" n'est pas un sel, il est appelé une "clé", et cela signifie que vous n'êtes plus le calcul d'un hash, mais un Code d'Authentification de Message (MAC). Le calcul de MAC est un travail délicat (beaucoup plus difficile que de simplement gifler ensemble d'une clé et d'une valeur dans une fonction de hachage, et il est très différent sujet tout à fait.

Le sel doit être aléatoire pour chaque instance dans lequel il est utilisé. Cela garantit qu'un attaquant n'a pour l'attaque de chaque salé de hachage séparément.
Si vous comptez sur votre sel (ou le salage algorithme) étant secret, vous entrez dans les domaines de la Sécurité Par l'Obscurité (ne fonctionne pas). Très probablement, vous n'obtenez pas de sécurité supplémentaire à partir du sel secret; vous obtenez juste l'ambiance chaleureuse et douillette de la sécurité. Ainsi, au lieu de rendre votre système plus sûr, c'est juste vous distrait de la réalité.

Alors, pourquoi ne le sel être aléatoire?

Techniquement, le sel doit être unique. Le point de la sel doit être distinct pour chaque mot de passe haché. Ceci est fait dans le monde entier. Puisqu'il n'existe pas d'organisme central qui distribue unique de sels sur demande, nous devons compter sur la prochaine meilleure chose, qui est la sélection aléatoire avec une imprévisible générateur aléatoire, de préférence au sein d'un sel de l'espace assez grand pour faire des collisions improbable (deux occurrences à l'aide de la même valeur salt).

Il est tentant d'essayer de tirer un sel de certaines données qui est "sans doute unique", comme l'ID utilisateur, mais ces régimes échouent souvent en raison de certains détails désagréables:

1. Si vous utilisez par exemple l'ID de l'utilisateur, des méchants, attaquer des systèmes distincts, peut tout simplement mettre leurs ressources en commun et de créer des tables précalculées pour l'utilisateur Id de 1 à 50. Un ID d'utilisateur est unique à l'échelle du système , mais pas dans le monde entier.

2. La même chose s'applique pour le nom d'utilisateur: il est une "racine" par le système Unix, mais il y a beaucoup de racines dans le monde. Un arc-en-ciel de la table pour "root" serait en vaut la chandelle, car elle pourrait être appliquée à des millions de systèmes. Pire encore, il y a aussi beaucoup de "bob" là-bas, et beaucoup n'ont pas sysadmin de formation: leurs mots de passe pourrait être assez faible.

3. L'unicité est aussi temporelle. Parfois, les utilisateurs de modifier leur mot de passe. Pour chaque nouveau mot de passe, un nouveau sel doit être sélectionné. Sinon, un attaquant a obtenu le hachage de l'ancien mot de passe et le hachage de la nouvelle pourrait essayer d'attaquer les deux simultanément.

À l'aide d'un hasard sel obtenu à partir d'un point de vue cryptographique sécurisé, imprévisible PRNG peut être une sorte de matraquage, mais au moins il prouvable vous protège contre tous ces dangers. Il n'est pas sur la prévention de l'attaquant de savoir ce qu'est un individu de sel, c'est de ne pas leur donner la grosse cible qui sera utilisé sur un grand nombre de cibles potentielles. La sélection aléatoire rend les cibles aussi mince que possible.

En conclusion:

Utiliser un hasard, uniformément répartie, de haute entropie de sel. L'utilisation d'un nouveau sel chaque fois que vous créez un nouveau mot de passe ou modifier un mot de passe. Stocker le sel avec le mot de passe haché. Faveur gros sels (au moins 10 octets, de préférence de 16 ans ou plus).

Un sel ne tourne pas un mauvais mot de passe dans un bon mot de passe. Il est tout à fait sûr que l'attaquant va au moins payer l'attaque de dictionnaire des prix pour chaque mot de passe incorrect, il rompt.

Utile sources:
stackoverflow.com: Non-aléatoire de sel pour le hachage de mots de passe
Bruce Schneier: Pratique de la Cryptographie (livre)
Matasano de Sécurité: Assez avec les Rainbow Tables
usenix.org: Unix utilisé sel depuis 1976
owasp.org: Pourquoi ajouter du sel
openwall.com: Sels

Avertissement:
Je ne suis pas un expert en sécurité. (Bien que cette réponse a été examiné par Thomas Pornin)
Si l'un des professionnels de la sécurité y trouver quelque chose de mal, s'il vous plaît ne commentaire ou modifier ce wiki réponse.

Answer 2

En réalité, les sels doivent être uniques pour chaque entrée. Même si l'attaquant peut calculer le sel, la table arc-en-ciel est extrêmement difficile à créer. En effet, le sel est ajouté au mot de passe avant son hachage. Il ajoute donc au nombre total d'entrées que la table arc-en-ciel doit contenir pour avoir une liste de toutes les valeurs possibles pour un champ de mot de passe.

Answer 3

Depuis Unix est devenu populaire, la bonne façon de stocker un mot de passe a été d'ajouter une valeur aléatoire (le sel) et de hachage. Enregistrer le sel de suite où vous pouvez obtenir d'elle plus tard, mais où on espère que les méchants ne l'obtiendra pas.

Cela a des bons effets. Tout d'abord, les méchants ne pouvez pas simplement faire une liste de prévu mots de passe comme "Password1", hash dans un arc-en-ciel de la table, et de passer par votre fichier de mot de passe à la recherche pour les matchs. Si vous avez un bon de deux octets de sel, ils doivent générer de 65 536 valeurs pour chaque attendus mot de passe, ce qui rend l'arc-en-ciel de la table beaucoup moins pratique. Deuxième, si vous pouvez garder le sel de la bad guys qui sont à la recherche à votre fichier de mot de passe, vous avez fait beaucoup plus de mal à calculer les valeurs possibles. Troisièmement, vous vous avez rendu impossible pour les méchants de déterminer si une personne utilise le même mot de passe sur plusieurs sites.

Pour ce faire, vous la génération aléatoire de sel. Cela devrait générer chaque numéro de la plage désirée avec une probabilité uniforme. Ce n'est pas difficile; un simple à congruence linéaire générateur de nombre aléatoire fera très bien l'affaire.

Si vous avez des calculs compliqués pour faire le sel, vous le faites mal. Si vous le calculez basé sur le mot de passe, vous êtes en train de faire beaucoup de mal. Dans ce cas, tout ce que vous faites est de compliquer la table de hachage, et ce n'est fonctionnellement, l'ajout de sel.

Personne n'bon à la sécurité dépendrait de la dissimulation d'un algorithme. La cryptographie moderne est basée sur des algorithmes qui ont été testées, et afin d'être testé, ils doivent être bien connus. En général, il a été trouvé à être plus sûr d'utiliser des algorithmes standard plutôt que de rouler propre et en espérant que c'est bon. Il n'importe pas si le code est open source ou pas, il est souvent encore possible pour les méchants pour analyser ce que le programme fait.

Answer 4

Vous pouvez simplement la génération aléatoire de sel pour chaque enregistrement au moment de l'exécution. Par exemple, dire que vous êtes le stockage de hachage des mots de passe utilisateur dans une base de données. Vous pouvez générer un 8 caractères chaîne de caractères aléatoires de bas en majuscules et en caractères alphanumériques au moment de l'exécution, ajoute que le mot de passe, hash que chaîne de caractères, et de le stocker dans la base de données. Puisqu'il y a 62⁸ possible sels, en générant des rainbow tables (pour chaque sel) sera d'un coût prohibitif; et puisque vous êtes à l'aide d'un salée unique pour chaque enregistrement de mot de passe, même si un attaquant a généré un couple de correspondance des tables arc-en-ciel, il ne pourra toujours pas de craquer à chaque mot de passe.

Vous pouvez modifier les paramètres de votre sel de la production basée sur vos besoins en matière de sécurité; par exemple, vous pouvez utiliser un plus de sel, ou de générer une chaîne de caractères aléatoires qui contient également des signes de ponctuation, pour augmenter le nombre de sels possibles.

Answer 5

L'utilisation d'une fonction aléatoire générateur pour produire le sel, et le stocker dans la base de données, faites sel, une par ligne, et de les stocker dans la base de données.

J'aime comment le sel est généré dans django-inscription. Référence: http://bitbucket.org/ubernostrum/django-registration/src/tip/registration/models.py#cl-85

salt = sha_constructor(str(random.random())).hexdigest()[:5]
activation_key = sha_constructor(salt+user.username).hexdigest()
return self.create(user=user,
		   activation_key=activation_key)

Il utilise une combinaison de sha généré par un nombre aléatoire et le nom d'utilisateur pour générer un hachage.

Sha lui-même est connu pour être solide et incassable. Ajouter plusieurs dimensions pour générer le sel lui-même, avec le nombre aléatoire, sha et l'utilisateur composant spécifique, vous avez incassable sécurité!