Existe-t-il un standard pour utiliser PBKDF2 comme mot de passe?

Question

Rejoignez-moi dans la lutte contre les hachages de mots de passe faibles. Un hachage de mot de passe PBKDF2 doit contenir le sel, le nombre d'itérations et le hachage lui-même. Il est donc possible de le vérifier ultérieurement. Existe-t-il un format standard, comme le {SSHA} du RFC2307, pour les hachages de mots de passe PBKDF2? BCRYPT est génial mais PBKDF2 est plus facile à implémenter.

Apparemment, il n'y a pas de spécification. Alors voici mes spécifications.

>>> from base64 import urlsafe_b64encode 
>>> password = u"hashy the \N{SNOWMAN}" 
>>> salt = urlsafe_b64decode('s8MHhEQ78sM=') 
>>> encoded = pbkdf2_hash(password, salt=salt) 
>>> encoded 
'{PBKDF2}1000$s8MHhEQ78sM=$hcKhCiW13OVhmLrbagdY-RwJvkA=' 

Mise à jour: http://www.dlitz.net/software/python-pbkdf2/ définit un remplacement crypt(). J'ai mis à jour mon petit spec pour correspondre à son, sauf ses débuts avec $p5k2$ au lieu de {PBKDF2}. (J'ai besoin de migrer loin des autres {LDAP} de style LDAP).

C'est {PBKDF2}, le nombre d'itérations en hexadécimal minuscule, $, le sel codé urlsafe_base64, $, et la sortie PBKDF2 codé urlsafe_base64. Le sel doit être de 64 bits, le nombre d'itérations doit être d'au moins 1000, et le PBKDF2 avec sortie HMAC-SHA1 peut avoir n'importe quelle longueur. Dans mon implémentation, il s'agit toujours de 20 octets (la longueur d'un hachage SHA-1) par défaut.

Le mot de passe doit être codé à utf-8 avant d'être envoyé à travers PBKDF2. Aucun mot sur si elle devrait être normalisée dans NFC d'Unicode.

Ce schéma devrait être de l'ordre de iterations fois plus coûteux que la force brute de {SSHA}.

Answer 1

Il existe une spécification pour les paramètres (sel et itérations) de PBKDF2, mais elle n'inclut pas le hachage. Ceci est inclus dans PKCS #5 version 2.0 (voir l'annexe A.2). Certaines plates-formes ont un support intégré pour l'encodage et le décodage de cette structure ASN.1. Puisque PBKDF2 est vraiment une fonction de dérivation de clé, cela n'a pas de sens de spécifier un moyen de regrouper le "hachage" (qui est vraiment une clé dérivée) avec les paramètres de dérivation — en utilisation normale, la clé doit rester secrète et n'est jamais stockée.

Mais pour une utilisation comme un hachage de mot de passe unidirectionnel, le hachage peut être stocké dans un enregistrement avec les paramètres, mais dans son propre champ.

Answer 2

Je vous rejoins dans la lutte contre hash faibles.

OWASP a une feuille de triche de stockage de mot de passe (https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet) avec quelques conseils; ils recommandent 64 000 itérations PBKDF2 minimum à partir de 2012, doublant tous les deux ans (à savoir 90 510 en 2012).

Notez que le stockage d'un long salt par utilisateur cryptographiquement aléatoire est toujours basique. Notez que le fait d'avoir un nombre d'itérations largement variable par utilisateur et de stocker le nombre d'itérations avec le sel ajoutera une certaine complexité au logiciel de craquage et peut empêcher certaines optimisations. Par exemple, "bob" est crypté avec 135817 itérations, alors que "alice" utilise 95.121 itérations, soit peut-être un minimum de (90510 + RAND (90510)) pour 2013.

Notez également que tout cela est inutile si les utilisateurs sont autorisés à choisir des mots de passe faibles comme "mot de passe", "Password1!"," P @ $$ w0rd ", et" P @ $$ w0rd123 ", qui seront trouvés très rapidement par les règles basées sur les attaques de dictionnaire (ce dernier est simplement" mot de passe "avec les règles suivantes: majuscule première lettre, 1337-parler, ajouter un nombre à trois chiffres à la fin.) Prenez une liste de base de dictionnaire (phpbb, pour une bonne, petite liste de mots de démarrage) et appliquez des règles comme ça, et vous ferez beaucoup de mots de passe Par conséquent, lors de la vérification de nouveaux mots de passe, n'appliquez pas "Tous les quatre supérieurs, inférieurs, chiffres, chiffres, au moins 11 caractères" car "P @ $$ w0rd123" est conforme à Au lieu de cela, utilisez cette liste de base de dictionnaire et voyez si les règles de base la casseraient (c'est beaucoup plus simple que d'essayer une fente - vous pouvez mettre en minuscule votre liste et leur mot, puis écrire simplement du code si les 4 derniers caractères sont une année commune, chec k sauf les quatre derniers caractères contre la liste de mots ", et" si les 3 derniers caractères sont des chiffres, cocher tous les caractères sauf les 3 derniers contre la liste de mots "et" cocher tous les caractères sauf les deux derniers "et 1337 le mot de passe - tournez @ en a, 3 en e, etc., puis vérifiez-le par rapport à la liste de mots et essayez aussi ces autres règles. "

En ce qui concerne les mots de passe, c'est génial , en particulier si d'autres caractères sont ajoutés au milieu des mots, mais si et seulement s'ils sont assez longs, puisque vous abandonnez beaucoup de combinaisons possibles.

Notez que les machines modernes avec GPU atteignent les dizaines de milliards d'hachages (MD5, SHA1, SHA-256, SHA-512, etc.) par seconde, même en 2012. En ce qui concerne la combinaison de mots "correct mot de passe de la batterie de cheval "type", celui-ci est au mieux un mot de passe très modeste - il est seulement 4 tous les mots anglais minuscules de longueur 7 ou moins avec des espaces. Donc, si nous cherchons des mots de passe de style XKCD avec 18 milliards de devinettes une seconde configuration: Un petit dictionnaire moderne anglais américain a: 6k mots de longueur 5 ou moins 21k mots de longueur 7 ou moins 36k mots de longueur 9 ou moins 46k mots Avec une phrase secrète de style XKCD, et sans prendre la peine de filtrer les mots par popularité («correct» vs «chaise» vs «dumpier» vs «hémorragie») de longueur 11 ou moins 49k mots de longueur 13 ou moins

nous avons 21k^4, ce qui ne représente que 2E17 possibilités. Avec une configuration de 18 milliards de seconde/seconde (une seule machine avec 8 GPU si nous sommes confrontés à une seule itération SHA1), cela fait environ 4 mois pour rechercher de manière exhaustive l'espace de clés. Si nous avions dix de ces configurations, cela prend environ deux semaines. Si nous excluons des mots improbables comme "dumpier", c'est beaucoup plus rapide pour un premier passage rapide. Maintenant, si vous obtenez des mots d'un "énorme" mot anglais américain, comme "Balsamina" ou "Calvinistically" (tous les deux choisis en utilisant la fonctionnalité "go to row", alors nous aurions 30k mots de longueur 5 ou moins 115k mots de longueur 7 ou moins 231k mots de longueur 9 ou moins 317k mots de longueur 11 ou moins 362k mots de longueur 13 ou moins

Même avec la limite de 7 longueur maximum, avec ce grand dictionnaire comme une base et des mots choisis au hasard, nous avons 115k^4 ~ = 1.8E20 possibilités, ou environ 12 ans si l'installation est tenue à jour (doublant en puissance tous les 18 mois) .Ceci est extrêmement similaire à un 13 caractères minuscules + nombre de mot de passe seulement. "300 ans" est ce que la plupart des estimations vous diront, mais ils ne tiennent pas compte de la loi de Moore