Est-il plus sûr de hacher un mot de passe plusieurs fois?

J'ai lu à quelques reprises que, lorsque vous stockez des mots de passe, il est judicieux de "doubler le hachage" des chaînes (par exemple, avec md5 puis sha1, les deux avec des sels, évidemment).

Je suppose que la première question est, "est-ce vraiment correct?" Si non, alors s'il vous plaît, rejetez le reste de cette question :)

La raison pour laquelle je pose cette question est que, à première vue, je dirais que cela a du sens. Cependant, quand j'y pense, chaque fois qu'un hachage est modifié (éventuellement avec quelque chose d'ajouté), tout ce que je peux voir, c'est qu'il y a une réduction de la limite supérieure de "l'unicité" finale ... cette limite étant liée à l'entrée initiale.

En d'autres termes: nous avons x nombre de chaînes qui, une fois hachées, sont réduites à y chaînes possibles. C'est-à-dire qu'il y a des collisions dans le premier set. Passons maintenant du deuxième ensemble au troisième, n’est-il pas possible que la même chose se produise (par exemple, des collisions dans l’ensemble des chaînes «y» possibles qui entraînent le même hachage dans le troisième ensemble)?

Dans ma tête, tout ce que je vois est un "entonnoir" pour chaque appel de fonction de hachage, "canalisant" un ensemble infini de possibilités en un ensemble fini, etc., mais il est évident que chaque appel travaille sur l'ensemble fini qui le précède, ce qui nous donne une ne définissez pas plus grande que l'entrée.

Peut-être qu'un exemple expliquera mes divagations? Prenez 'hash_function_a' qui donnera 'a' et 'b' le hash '1' et donnera 'c' et 'd' le hash '2'. En utilisant cette fonction pour stocker les mots de passe, même si le mot de passe est 'a', je pourrais utiliser le mot de passe 'b'.

Prenez 'hash_function_b' qui donnera '1' et '2' le hash '3'. Si je devais utiliser ce comme un « hachage secondaire » après « hash_function_a » alors même si le mot de passe est « un » je pourrais utiliser « b », « c » ou « d ».

En plus de tout cela, je comprends que les sels devraient être utilisés, mais ils ne changent pas vraiment le fait que chaque fois que nous mappons les entrées 'x' à des sorties 'inférieures à x'. Je ne pense pas.

Quelqu'un peut-il m'expliquer s'il vous plaît ce qui me manque ici?

Merci!

EDIT: pour ce que ça vaut, je ne le fais pas moi-même, j'utilise bcrypt. Et je ne me préoccupe pas vraiment de savoir si c'est utile ou non pour "utiliser des cycles" pour un "pirate informatique". Je me demande vraiment si le processus réduit ou non la "sécurité" du point de vue de la collision de hash.

Ceci est plus adapté sur security.stackexchange mais ...

Le problème avec

hash1(hash2(hash3(...hashn(pass+salt)+salt)+salt)...)+salt)

est que cela est aussi fort que la fonction de hachage la plus faible de la chaîne. Par exemple, si hashn (le hachage le plus à l'intérieur) donne une collision, toute la chaîne de hachage donnera une collision ( quels que soient les autres hachages dans la chaîne ).

Une chaîne plus forte serait

hash1(hash2(hash3(...hashn(pass + salt) + pass + salt) + pass + salt)...) + pass + salt)

Ici, nous évitons le problème de collision précoce et générons essentiellement un sel qui dépend du mot de passe du hachage final.

Et si une étape de la chaîne entre en collision, cela n'a pas d'importance, car à l'étape suivante, le mot de passe est utilisé à nouveau et doit donner un résultat différent pour des mots de passe différents.

L'utilisation d'algorithmes de hachage différents est une mauvaise idée - elle réduira l'entropie au lieu de l'augmenter.

Cependant, en supposant que vous disposiez d'un algorithme de hachage fort sur le plan cryptographique et d'un bon sel, l'application répétée de la même fonction de hachage rend le processus de hachage plus onéreux. L'avantage de cela est que, lorsque d'autres moyens de déchiffrer le hachage du mot de passe échouent (devinettes, attaques par dictionnaire, tables arc-en-ciel, etc.) et que l'attaquant est forcé d'utiliser des techniques de force brute, il leur faut plus de temps pour essayer chaque mot de passe, simplement parce que ils doivent appliquer la même fonction de hachage plus souvent. Donc, si un cycle de hachage nécessitait un mois de force brute, son application douze fois augmenterait le temps estimé à un an.

Les algorithmes de hachage récents tels que bcrypt reposent sur cette idée; ils contiennent un paramètre permettant de contrôler la complexité de calcul du hachage, de sorte que vous puissiez l’adapter à mesure que le matériel avance: lorsque le matériel devient plus rapide d'un facteur deux, vous augmentez la complexité pour compenser, de sorte que le temps nécessaire pour forcer brutalement votre le hachage reste à peu près constant.

N'essayez pas d'écrire votre propre schéma de hachage de mot de passe, à moins que vous ne souhaitiez suivre un cours de cryptographie et / ou d'ingénierie de la sécurité.

Vous devez utiliser une implémentation bien établie du hachage de mot de passe, qui doit à son tour utiliser une fonction de dérivation de clé ( KDF ) telle que PBKDF2, bcrypt, scrypt ou le plus récent Argon2.

Les bonnes KDF incluent un facteur de travail, généralement un certain nombre d'itérations, afin d'augmenter le coût des attaques hors ligne. On pourrait dire que ces fichiers KDF hachent le mot de passe plusieurs fois, en utilisant le même algorithme à chaque fois. Il est inutile d'utiliser l'algorithme de résumé de messages multiples, comme l'ont souligné d'autres personnes.

En général, il n'est pas nécessaire d'utiliser plus d'un algorithme de hachage.

Ce que vous devez faire c'est:

Utilisez le sel: le sel ne sert pas juste pour votre mot de passe plus sécurisé , il est utilisé pour attaquer la table arc -en -Aboid. De cette façon, quelqu'un aura plus de difficulté à précalculer le hachage des mots de passe que vous stockez dans votre système.

Utilisez plusieurs interactions: au lieu de simplement faire SHA (mot de passe + sel), faites SHA (SHA (SHA (SHA (SHA (... mot clé SHA).).))). Ou, pour représenter autrement:

hash = sha(password + salt)
for i=1 , i=5000, i++ {
    hash = sha(hash + salt);
}

Et, enfin, choisissez une bonne fonction de hachage. SHA, MD5, etc., ne sont pas bons parce qu'ils sont trop rapides . Puisque vous voulez utiliser le hachage comme protection, vous feriez mieux d'utiliser des hachages plus lents. Jetez un coup d'œil à Bcrypt , PBKDF2 ou Scrypt , par exemple.

edit : après les observations, essayons de voir quelques points (désolé, longue explication pour arriver à la fin, car cela pourrait aider les autres à chercher des réponses similaires):

Si votre système est sécurisé, comme personne ne pourra jamais accéder au mot de passe stocké, vous n'avez pas besoin de hachage. Le mot de passe serait secret, personne ne le comprendrait.

Mais personne ne peut garantir que la base de données contenant les mots de passe sera volée. Voler la base de données, a tous les mots de passe. Ok, votre système et votre entreprise en subiront toutes les conséquences. Donc, nous pourrions essayer d'éviter cette fuite de mot de passe.

AVIS que nous ne sommes pas inquiets des attaques en ligne sur ce point. Pour une attaque en ligne, la meilleure solution consiste à ralentir après des mots de passe incorrects, à verrouiller le compte après quelques tentatives, etc. Une attaque en ligne consiste à ralentir les entrées de mot de passe .

Revenons donc au don't let them take my plain passwordsproblème. La réponse est simple: ne les stockez pas sous forme de texte brut. Ok, j'ai compris.

Comment éviter ça?

Crypter le mot de passe (?). Mais, comme vous le savez, si vous le chiffrez, vous pouvez le déchiffrer si vous avez la clé appropriée. Et vous vous retrouverez avec le problème de "où cacher" la clé. Hum, ça ne va pas, puisqu'ils vous ont eu la base de données, ils peuvent avoir votre clé. Ok, ne l'utilisons pas.

Donc, une autre approche: transformons le mot de passe en quelque chose d'autre qui ne peut pas être inversé et stockons-le. Et pour vérifier si le mot de passe fourni est correct, nous répétons le même processus et vérifions si les deux valeurs transformées correspondent. S'ils correspondent = le bon mot de passe a été fourni.

Ok, jusqu'ici tout va bien. Utilisons du hash MD5 dans le mot de passe. Mais ... si quelqu'un a notre valeur de mot de passe hachée stockée, il peut disposer de beaucoup de puissance informatique pour calculer le hachage MD5 de chaque mot de passe possible (force brute), afin de pouvoir trouver le mot de passe d'origine. Ou, pire encore, il peut stocker tous les MD5 de toutes les combinaisons de caractères et trouver facilement le mot de passe. Donc, faites beaucoup d'itérations, la chose HASH (HASH (HASH () ())), pour rendre les choses plus difficiles, parce que cela prendra plus de temps.

Mais même si cela peut être évité, la table arc-en-ciel a été créée pour accélérer ce genre de protection.

Alors, utilisons du sel dessus. De cette façon, à chaque interaction, le sel est réutilisé. Celui qui essaiera d’attaquer vos mots de passe devra générer la table arc-en-ciel en considérant que le sel est ajouté à chaque fois. Et quand il génère cette table arc-en-ciel, puisqu'elle a été générée avec un sel, il devra calculer à nouveau avec l'autre sel, il devra donc passer du temps pour chaque mot de passe (= chaque sel). Salt n’ajoutera pas "plus de complexité" au mot de passe, il laissera simplement à l'attaquant le temps de générer la table arc-en-ciel. Si vous utilisez un sel pour chaque mot de passe, la table d'un sel est inutile pour un autre.

Et en utilisant plus d'un hash aura aidé ici? Non. La personne générant une attaque arc-en-ciel spécifique sera capable de la générer en utilisant un ou plusieurs hashes, de toute façon.

Et utiliser plus d'un hash peut vous mener à un problème: c'est aussi sécurisé que le hash le plus faible que vous utilisez. Si quelqu'un trouve des collisions dans un algorithme de hachage, c'est ce hachage qui sera exploité, à tout moment du processus d'itération, pour casser le mot de passe. Donc, vous ne gagnez rien en utilisant plus d'algorithmes de hachage, il vaut mieux choisir un seul bon algo. et l'utiliser. Et si vous entendez dire qu'il a été cassé, réfléchissez à la façon dont vous allez le changer dans votre application.

Et pourquoi utiliser bcrypt ou quelque chose comme ça (vous dites que vous l'utilisez): parce que l'attaquant devra passer plus de temps à générer les tables. C’est pourquoi l’utilisation de MD5 + wait (3 secondes) n’aide pas: l’attaque sera hors ligne, de toute façon, afin que l’attaquant puisse générer les tables sans le (délai de 3 secondes).

Je crois comprendre que l’utilisation de plusieurs algorithmes de hachage consiste à vaincre les tables arc-en-ciel . Utiliser un bon sel marche aussi, mais je suppose que c'est un deuxième niveau de protection.

Ce n'est pas plus sécurisé. Cependant, vous disposez d'un protocole d'identification basé sur le hachage plusieurs fois avec la même fonction.

Cela se passe comme ça. La valeur stockée est hash ^ n (pass) dans l'ordinateur A. A demande à B de s'authentifier et donne à B le nombre entier n. B fait le calcul hash ^ (n-1) (passe) et le renvoie à A.

Une vérification qui hash (hash ^ (n-1) (pass)) == hash ^ n (pass). Si c'est vrai, alors l'authentification est faite. Mais alors, un magasin hash ^ (n-1) (passe) et la prochaine authentification donnera B n-1 au lieu de n.

Cela garantit que le mot de passe n'est jamais échangé en clair, que A ne sait jamais ce que le mot de passe est et que l'authentification est protégée par la relecture. Cependant, cela a l'inconvénient d'exiger un mot de passe avec une durée de vie limitée. Lorsque n atteint la valeur 2, un nouveau mot de passe doit être choisi après authentification.

L'outil HMAC est une autre utilisation du hachage multiple, qui garantit l'authentification et l'intégrité d'une requête. Pour plus d'informations sur HMAC, voir http://en.wikipedia.org/wiki/HMAC .

La plupart des utilisations de hachage multiple dans le monde réel sont excessives. Dans votre cas, cela semble être le cas. Notez que si vous utilisez plusieurs fonctions de hachage, elles n'auront pas toutes la même entropie, ce qui réduira la force de hachage. Par exemple, md5 a moins d'entropie que sha1, donc utiliser sha1 sur un md5 n'améliorera pas la force du hachage. La force sera généralement égale à la force de la fonction de hachage plus faible.