Quel est le sel dans Enterprise Library HashProvider? (Touche SaltEnabled)

Question

Comment le sel est-il généré dans HashProvider dans Microsoft Enterprise Library lorsque nous définissons SaltEnabled?

Est-ce aléatoire pour les nouvelles machines? Est-ce un nombre magique?

(je sais ce qui est un sel, la question est quelle est la valeur réelle d'un/sel dans Enterprise Library HashProvider)

Answer 1

Edit:

Voir Microsoft.Practices.EnterpriseLibrary.Security.Cryptography. HashAlgorithmProvider pour un exemple d'implémentation. Les étapes de hachage sont:

1. Si SaltEnabled, générez des octets aléatoires pour la longueur de sel à l'aide de RNGCryptoServiceProvider.
2. Ajouter le sel au texte en clair.
3. Écrasez le texte en clair salé.
4. Ensuite (c'est l'étape importante), ajoutez de nouveau le sel au .

Pour comparer contre le texte haché, vous devez utiliser:

public bool CompareHash(byte[] plaintext, byte[] hashedtext) 

contre ressasser et de comparer. Si vous ressentez, un nouveau sel aléatoire est généré et vous êtes perdu.

CompareHash effectue les opérations suivantes:

1. tire le sel non haché au large de la hashtext. Rappelez-vous, il a été ajouté à l'étape 4 ci-dessus.
2. Utilise ce sel pour calculer un hachage pour le texte en clair.
3. Compare le nouveau hachage avec le hashedtext moins le sel. Si elles sont identiques - vrai, sinon faux.

d'origine:.

« si le sel est activé sur un HashProvider, le fournisseur va générer une séquence aléatoire d'octets, qui sera ajouté à la table de hachage Si vous comparez une valeur de hachage avec une valeur non hachés, le sel sera extrait de la valeur hachée et utilisé pour hacher la valeur non hachée, avant la comparaison. "

et

« En ce qui concerne le décodage comme valeur de hachage. Ce ne peut pas être fait. Après la création d'une table de hachage il devrait y avoir aucun moyen d'inverser cela en la valeur d'origine. Cependant, ce que vous pouvez faire est de comparer un valeur non hachée avec une valeur hachée en la faisant passer par le même algorithme et en comparant la sortie. "

De http://www.codeplex.com/entlib/Thread/View.aspx?ThreadId=10284

Answer 2

Légèrement offtopic:

Ce sel est utilisé pour prévenir les attaques de Rainbow. Une attaque arc-en-ciel est un type de tentative pour trouver quelle était la chaîne pour laquelle ce hachage a été calculé sur la base d'un très grand dictionnaire (exhaustif/plusieurs gigaoctets habituellement) de hachages précalculés.

'Uncle' Jeff a un blog entry about this.

De plus, vous pouvez regardez Wikipedia:

http://en.wikipedia.org/wiki/Rainbow_table

Answer 3

Je suis quelques années trop tard, je suppose, mais je crois comprendre qu'une nouvelle valeur de sel aléatoire est créé à chaque fois que vous créez un hacher.

Answer 4

J'ai répondu à une question similaire concernant la bibliothèque d'entreprise et la valeur de sel qu'elle utilise pour le hachage.

Vous pouvez voir ici: https://stackoverflow.com/a/27247012/869376

Les points forts:

1. Le sel est un tableau de 16 octets généré de façon aléatoire. Il est généré via la méthode CryptographyUtility.GetRandomBytes(16); dans l'espace de noms Microsoft.Practices.EnterpriseLibrary.Security.Cryptography. Cette suite appelle une méthode de bibliothèque C appelée [DllImport("QCall", CharSet = CharSet.Unicode)] private static extern void GetBytes(SafeProvHandle hProv, byte[] randomBytes, int count);
2. Les 16 premiers octets de la chaîne Base64 est le sel qui a été utilisé pour hacher la valeur d'origine