Question:
System.Cryptology.RFC2898DeriveBytes () basé sur PBKDF2 est-il «meilleur» pour le hachage de mot de passe Unicode que les méthodes traditionnelles?
goodguys_activate
2011-02-08 14:57:11 UTC
view on stackexchange narkive permalink

Quand est-il approprié d'utiliser RFC2898DeriveBytes par rapport à un hachage typique?

Update↑

Je comprends maintenant qu'un KDF est généralement utilisé pour créer une clé symétrique pour une utilisation possible dans le chiffrement d'un flux. Je comprends également maintenant que PBKDF2 rend obsolète PasswordDeriveBytes. Le but de cette question est d'explorer la possibilité de réutiliser le KDF comme un moyen efficace de stocker un mot de passe haché. Le contenu que j'ai l'intention de chiffrer est une chaîne Unicode dont un humain peut se souvenir et taper dans un ordinateur.

La raison pour laquelle je suis intéressé par le KDF est parce qu'il est

  1. Lent, et donc coûteux en calcul pour créer une table arc-en-ciel
  2. La bibliothèque de base en .NET est approuvée FIPS et il est possible d'utiliser ce KDF avec recommandations NIST si nous utilisons SHA 256

Question

Quels sont les arguments pour / contre l'utilisation d'un KDF de cette manière par opposition à la méthode de hachage normale ? (Clause de non-responsabilité: quelle est la méthode de hachage normale?)

Notez, d'après la réponse donnée par @Thomas_Pornin,, que cela ne convient pas pour le stockage des mots de passe. En général, vous ne souhaitez pas stocker de mots de passe, vous souhaitez stocker quelque chose qui vous permet uniquement de vérifier que l'utilisateur a présenté le bon mot de passe - voir [Password hashing - IT Security] (http://security.stackexchange.com/questions / 211 / hachage de mot de passe). Pour d'autres cas, voir par ex. [Stockage sécurisé des informations d'authentification tierces - Sécurité informatique] (http://security.stackexchange.com/questions/1335/storing-third-party-auth-info-securely)
Il est triste que la documentation Microsoft à laquelle vous faites référence sur PasswordDeriveBytes se réfère à «IETF RRC 2898». Ils signifient [RFC 2898] (http://tools.ietf.org/html/rfc2898), qui décrit plus de considérations d'utilisation et de sécurité.
Juste pour clarifier les commentaires à ce jour: PBKDF1 est obsolète. Il est remplacé par l'objet crypto .NET nommé: [RFC2898DeriveBytes] (http://msdn.microsoft.com/en-us/library/system.security.cryptography.rfc2898derivebytes.aspx)
Je note la question sensiblement modifiée. Le lien "approuvé par la FIPS" vers ma réponse à une autre question semble trompeur. Là, je faisais seulement allusion à un argument selon lequel les primitives de PBKDF2, si ajustées pour utiliser SHA-256 plutôt que le SHA-1 par défaut, correspondraient aux recommandations actuelles du NIST. Mais je n'ai vu aucune spécification FIPS sur le hachage de mot de passe. Mon point principal était que blowfish (bcrypt) n'est clairement pas sur la liste du NIST, alors que SHA-1 l'était et SHA-256 l'est maintenant.
@nealmcb - Les liens semblent-ils plus précis et plus clairs?
Heh - donc j'ai un vague souvenir que RFC2898DeriveBytes autorise l'utilisation d'autres hachages, mais je ne fais pas .NET. Avez-vous confirmé cela? Pouvez-vous nous donner un extrait de la façon d'utiliser HMAC-SHA-256 avec? En outre, la bibliothèque est-elle en fait certifiée FIPS ou est-ce simplement qu'elle implémente un algorithme approuvé? Enfin, quels paramètres prévoyez-vous d'utiliser pour la longueur du sel (64?) Et les itérations (1000? 4000?)?
Related: [Le NIST recommande-t-il vraiment PBKDF2 pour le hachage de mot de passe?] (http://security.stackexchange.com/questions/15065/does-nist-really-recommend-pbkdf2-for-password-hashing)
Six réponses:
#1
+16
Thomas Pornin
2011-02-08 17:58:52 UTC
view on stackexchange narkive permalink

PasswordDeriveBytes implémente la fonction de dérivation de clé PBKDF1. Un KDF est une fonction qui transforme une donnée secrète (ici, un «mot de passe», c'est-à-dire le type de données qui tient dans un cerveau humain et peut être tapé avec des doigts humains) en une séquence de bits adéquate pour les algorithmes qui nécessitent un clé symétrique (par exemple, cryptage symétrique). Un KDF n'est pas destiné à autre chose, en particulier au stockage des mots de passe.

Une fonction de hachage peut être utilisée comme un KDF, à condition que la clé symétrique dont vous avez besoin ne dépasse pas la taille de sortie de la fonction de hachage. Cependant, un tel KDF serait très grossier. Une fonctionnalité que le bon KDF devrait fournir est d'être suffisamment lent . En effet, les "mots de passe" sont, par nature, vulnérables à la recherche exhaustive (également appelée "attaque par dictionnaire": les utilisateurs ont tendance à choisir comme mots de passe des mots ou des combinaisons plutôt simples qui ne peuvent être devinés qu'en quelques millions ou milliards d'essais). Dans un système donné, on peut généralement tolérer un KDF relativement lent: un utilisateur essayant de s'authentifier ne verra pas la différence entre un retard de 1µs et un retard de 1ms pour la fonction de dérivation de clé; mais un ralentissement de 1000x est mortel pour l'attaquant: il convertit un effort de rupture d'une journée en un effort de rupture de trois ans .

PBKDF1 inclut un "nombre d'itérations" qui est un paramètre destiné exactement à cela: rendre la dérivation de clé suffisamment lente, de manière configurable. Une simple fonction de hachage est trop rapide pour cela. L'utilisation en tant que KDF est précisément là où vous préférez PBKDF1 à une fonction de hachage. En fait, PBKDF1 n'est pas recommandé; PBKDF2, du même standard, est censé être plus robuste.

Les fonctions de hachage sont des objets beaucoup plus génériques que KDF, et ont de nombreuses autres utilisations, que KDF ne remplit pas.

Ce que vous voulez faire n'est pas clair: vous utilisez le terme «signature», qui signifie normalement «signature numérique asymétrique» comme avec RSA ou ECDSA; il y a des gens qui ont tendance à utiliser le terme «signature» pour désigner un contrôle d'intégrité symétrique, comme un MAC (l'appeler une «signature» est incorrect, mais répandu). Cependant, cela implique un morceau de secret à un moment donné, une clé et une fonction de hachage est sans clé.

+1 pour expliquer les détails * beaucoup * mieux que moi.
Merci pour la bonne réponse. J'ai également trouvé ce lien sur MSDN qui fournit encore plus de détails
.. lien vers MSDN: http://blogs.msdn.com/b/shawnfa/archive/2004/04/14/113514.aspx
@Thomas Quelle est la manière correcte de stocker un mot de passe si ce n'est PBKDF2?
Lien: Comment * devrait-on * crypter un mot de passe si ce n'est par un KDF: http://security.stackexchange.com/questions/2131/reference-implementation-of-a-c-hash-for-secure-password-storage
@Thomas RFC2898 indique que PBKDF1 peut être utilisé pour la vérification du mot de passe, [`où la sortie de la fonction de dérivation de clé est stockée (avec le sel et le nombre d'itérations) aux fins de la vérification ultérieure d'un mot de passe`] (http: // www. ietf.org/rfc/rfc2898.txt) Pouvez-vous clarifier votre réponse?
Pour le stockage des mots de passe, vous voulez une fonction unidirectionnelle avec une sortie fixe suffisamment grande. Pour la dérivation de clé, vous voulez une fonction sans collision avec une taille de sortie configurable. Il est concevable de créer un KDF qui _aussi_ a des caractéristiques de sécurité suffisamment bonnes pour le stockage des mots de passe (en supposant que vous utilisez une taille de sortie correcte et fixe), mais ce n'est pas automatique. PBKDF2 a été publié en tant que KDF et a été analysé en tant que tel. Il reste à prouver s'il peut être transformé en un mécanisme de stockage de mots de passe.
@makerofthings, votre devis est hors contexte. En fait, RFC2898 disait spécifiquement, il y a 10 ans, que PBKDF1 n'est pas recommandé pour de nouvelles applications. Sur la base du commentaire d'@Thomas', je dirais que vous voudrez peut-être au moins utiliser PBKDF2 qui peut produire une sortie plus longue.
Merci. Cela signifie-t-il que PBKDF2 crée une sortie meilleure que toute autre telle qu'un hachage SHA 256? (à des fins de stockage des mots de passe et de comparaison ultérieure)?
@makerofthings, comme l'explique @Thomas, PBKDF2 est conçu et destiné à la dérivation de clé, plutôt qu'au stockage de mots de passe. Peut-être que cela aiderait à clarifier la question d'origine, ou à publier une nouvelle question, d'une manière qui explique dans quel but vous voulez cette primitive cryptographique?
@D.W. - Question clarifiée. Merci pour le conseil.
@D.W. @Thomas Mais notez la section citée par @makerofthings dans laquelle la RFC prévoit d'utiliser les fonctions de stockage des vérificateurs de mots de passe. Je ne comprends pas non plus pourquoi la longueur même de PBKDF1 pourrait être insuffisante. Des hachages plus longs donnent des tables arc-en-ciel légèrement plus longues, mais cela n'a pas d'importance étant donné la protection par défaut de 64 bits contre le sel, non?
@D.W. @Thomas @nealmcb fyi - J'ai trouvé un autre gourou qui recommande d'utiliser PBKDF2 pour hacher un mot de passe: http://www.daemonology.net/blog/2009-06-11-cryptographic-right-answers.html
#2
+14
goodguys_activate
2011-09-06 00:07:25 UTC
view on stackexchange narkive permalink

Le NIST approuve PBKDF2 lors du hachage et du stockage des mots de passe, mais ce n'est pas son objectif initial. Notamment, StackExchange utilise également PBKDF2 dans le même but. Le code source est disponible ici.

Voir cette réponse pour une comparaison entre BCrypt et PBKDF2. BCrypt est la méthode la plus conventionnelle de stockage des mots de passe.

J'envisage PBKDF2 car il est intégré à .NET et est déjà compatible FIPS.

Je ne suis pas d'accord sur le "nist-sp800-132" approuve PBKDF2 pour "hachage et stockage des mots de passe". Il parle en fait de l'utilisation de PBKDF2 en tant que KDF pour dériver des clés de protection des données qui sont utilisées pour crypter les données stockées.
#3
+6
AviD
2011-02-08 16:22:36 UTC
view on stackexchange narkive permalink

Sauf si j'ai manqué quelque chose, PasswordDeriveBytes - et d'autres implémentations de PBKDF - ne sont pas destinés à stocker des mots de passe, ni à être utilisés à la place d'un hachage "typique".

Son but est de créer une clé de cryptage, pour un cryptage symétrique, basée sur un mot de passe fourni par l'utilisateur.

Pour clarifier, considérez la situation suivante:
Vous avez une application, qui nécessite de crypter un fichier. Ceci est fait à la discrétion de l'utilisateur, et peut être déchiffré à son choix.
Oh, disons que MS Word a une fonction pour crypter son contenu. Ou un fichier ZIP chiffré.
Vous voulez donner à l'utilisateur le contrôle pour y accéder, mais vous ne voulez pas compter sur l'utilisateur pour générer une clé forte, aléatoire, exactement de 256 bits, ce qui la rendrait difficile à retenir, etc.
Ainsi, vous autorisez l'utilisateur à définir le mot de passe qu'il veut - et dérivez la clé de chiffrement à partir de là.

À aucun moment vous ne stockez le mot de passe, ni n'utilisez un simple hachage pour le stocker. Il est uniquement destiné à la création de matériel clé.

#4
+4
nealmcb
2011-02-15 23:57:21 UTC
view on stackexchange narkive permalink

PBKDF2 est meilleur que PBKDF1, qui était obsolète dans la RFC 2898 il y a 10 ans. Il est implémenté pour .NET dans la classe Rfc2898DeriveBytes (System.Security.Cryptography)

Je suis heureux de voir également qu'à partir de Java 6, il existe une implémentation de PBKDF2: PBKDF2WithHmacSHA1 dans SunJCE.

Pour les versions antérieures de Java, comme indiqué dans BlackBerry App Security - Stack Overflow, une implémentation de PBKDF2 se trouve dans Une implémentation Java gratuite de RFC 2898 / PKCS # 5 PBKDF2

Je me demande cependant si l'utilisation de SHA-256 serait meilleure que SHA-1, qui est maintenant obsolète.

Je me demande si l'utilisation de SHA-256 serait également meilleure.
#5
+3
jbtule
2011-03-02 04:12:43 UTC
view on stackexchange narkive permalink

Utiliser RFC2898DeriveBytes avec un nombre d'itérations non trivial devrait être mieux que d'utiliser une fonction de hachage simple à des fins d'authentification.

Tout d'abord, il vous faut mettre un sel, et bien qu'il soit toujours possible pour le développeur de faire quelque chose de stupide comme coder en dur le sel, c'est au moins un pas de plus que là où les développeurs se trompent normalement, ce qui n'est pas du sel et tout. Le simple fait d'avoir un sel rend moins probable qu'une table arc-en-ciel déjà disponible fonctionnera sur un mot de passe trivial et si vous salez au hasard pour chaque utilisateur, cela arrête les fuites d'informations lorsque plusieurs utilisateurs ont le même mot de passe et rend ces mots de passe faciles très difficiles à utiliser. get parce que vous auriez à générer une table pour chaque sel.

2ème alors que RFC2898DeriveBytes ne vous laisse malheureusement pas choisir la fonction de hachage et utilise HMAC-SHA1 et ce n'est pas vraiment un problème car la bonne chose à propos de par rapport à PBKDF1, la taille de votre clé peut être aussi grande que vous le souhaitez. Cela aide à rendre difficile le stockage et la diffusion des tables arc-en-ciel par rapport à tout algorithme de hachage standard.

Enfin, le nombre d'itérations est essentiel! Avoir un nombre très élevé de ralentissements et de calculs de hachage, les algorithmes de hachage standard sont conçus pour être rapides, le stockage des données augmente de façon exponentielle, vous ne pouvez pas compter uniquement sur la taille de votre clé.

#6
+1
mrnap
2011-03-02 08:48:19 UTC
view on stackexchange narkive permalink

La question du PO et le but de ladite question sont quelque peu contradictoires. Comme tout le monde le souligne, PBKDF2 n'est pas principalement utilisé pour l'enc / stockage des mots de passe, mais la génération de clés. Le plus souvent, il est utilisé dans WPA2 PMK et d'autres schémas de génération de clés WPA, en utilisant des exemples de composants comme le mot de passe + un sel du nom SSID et la longueur du nom SSID, qui sont ensuite exécutés via un hachage SHA1 d'itération 4096.

Lors du chiffrement, les choses les plus importantes à exiger pour des raisons de sécurité sont la longueur et un sel qui est dynamique et non transparent pour l'utilisateur (c'est-à-dire que l'exploitant ne peut pas déterminer ce qu'est le sel). Si vous utilisez un magasin crypté AES avec un mot de passe minimum de 20 caractères, un sel aléatoire et 4 k + itérations de SHA-256 (PBKDF2 recommande au moins 1 k itérations de SHA1 à ses fins), un hacker va avoir beaucoup de mal à casser ce mot de passe (voir: ordre de grandeur en années ou en décennies sinon plus).

Le cryptage des mots de passe dépend également fortement de l'utilisation finale (vitesse, nécessité du niveau de sécurité, etc.), donc sans savoir quelle utilisation finale potentielle est il est plus difficile de recommander une solution idéale.

Pour la plupart des schémas de cryptage salés qui sont utilisés dans la nature, le sel n'est pas caché. Ce n'est pas une restriction utile. Vous ne pouvez pas légitimement reproduire le hachage si vous ne connaissez pas le sel.


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 2.0 sous laquelle il est distribué.
Loading...