J'ai vu un gars qui crypter les utilisateurs passe mot de passe plusieurs fois avec MD5 pour améliorer la sécurité. Je ne suis pas sûr que cela fonctionne, mais cela n'a pas l'air bien. Alors, ça a du sens?
4 Réponses :
Non, ce n'est pas une bonne pratique, vous devez utiliser un sel $ pour votre cryptage car le mot de passe Cand soit fissuré avec ces tables arc-en-ciel
hachage Un mot de passe n'est pas du cryptage. C'est un processus à sens unique.
Consultez Security.stackexchange.com et les questions relatives au mot de passe. Ils sont si populaires que nous mettons ensemble Ce blog post spécifiquement pour aider les personnes à trouver des questions et réponses utiles.
Cette question discute spécifiquement de l'utilisation de MD5 20 fois de suite - Vérifiez la réponse de Thomas Pornin. Points clés dans sa réponse:
Supposons que la fonction de hachage que vous utilisez serait une fonction à sens unique. Ensuite, vous pouvez afficher sa sortie comme celle d'un "Oracle aléatoire" , ses valeurs de sortie sont dans un plage finie de valeurs (2 ^ 128 pour MD5).
Que se passe-t-il si vous appliquez le hachage plusieurs fois? La sortie restera toujours dans la même plage (2 ^ 128). C'est comme si tu dis "devinez mon nombre aléatoire!" Vingt fois, chaque fois en pensant à un nouveau numéro - qui ne le rend pas plus difficile ou plus facile à deviner. Il n'y a pas de "plus aléatoire" que aléatoire. Ce n'est pas une analogie parfaite, mais je pense que cela aide à illustrer le problème.
Considérant une brute-forçage d'un mot de passe, votre schéma n'ajoute aucune sécurité du tout. Pire encore, la seule chose que vous pourriez "accomplir" est d'affaiblir la sécurité en introduisant une possibilité d'exploiter l'application répétée de la fonction Hash. Il est peu probable, mais au moins, il est garanti que vous ne gagnez certainement rien.
Alors pourquoi n'est-il toujours pas perdu avec cette approche? C'est à cause de la notion que les autres ont fait pour avoir des milliers d'itérations au lieu de vingt vingt. Pourquoi est-ce une bonne chose, ralentissant l'algorithme? C'est parce que la plupart des attaquants essaieront d'accéder à l'aide d'un dictionnaire (ou Table arc-en-ciel en utilisant des mots de passe souvent utilisés. J'espère que l'un de vos utilisateurs était suffisamment négligent d'utiliser l'un de ceux-ci (je suis coupable, au moins Ubuntu m'a dit lors de l'installation). Mais d'autre part, il est inhumain d'exiger que vos utilisateurs se souviennent, disons 30 caractères aléatoires. < / p>
C'est pourquoi nous avons besoin d'une forme de compromis entre des mots de passe faciles à retenir, mais en même temps le rendant le plus difficile possible pour les attaquants de les deviner. Il existe deux pratiques communes, sels et ralentissez le processus en appliquant beaucoup d'itérations de certaines fonctions au lieu d'une seule itération. PKCS # 5 est un bon exemple à examiner.
Dans votre cas, appliquer MD5 20000 au lieu de 20 fois, les attaquants ralentissaient de manière significative un dictionnaire de manière significative, car chacun de leurs mots de passe d'entrée devrait passer par la procédure ordinaire d'être hachée 20000 fois afin d'être toujours utile comme une attaque . Notez que cette procédure pas affecte la forçage brute comme illustré ci-dessus.
Mais pourquoi utiliser un sel encore mieux? Étant donné que même si vous appliquez le HASH 20000 fois, un attaquant de débrouillard pourrait pré-calculer une grande base de données de mots de passe, chacun d'entre eux 20000, générant efficacement une table arc-en-ciel personnalisée spécifiquement ciblée à votre application. Après avoir fait cela, ils pourraient facilement attaquer votre application ou toute autre application à l'aide de votre système. C'est pourquoi vous devez également générer un coût élevé par mot de passe, pour rendre les tables arc-en-ciel irréalistes à utiliser.
Si vous voulez être du côté vraiment sûr, utilisez quelque chose comme PBKDF2 illustré dans PKCS n ° 5.
Il y a une telle question sur Crypto.se mais ce n'est pas public maintenant. La réponse de Paŭlo Ebermann est:
Pour le hachage de mots de passe, vous ne devez pas utiliser de hachage cryptographique normal, Mais quelque chose fait spécialement pour protéger les mots de passe, comme Bcrypt.
voir Comment stocker en toute sécurité un mot de passe pour plus de détails.
Le point important est que les craquelins de mot de passe ne doivent pas avoir à bruteforcer l'espace de sortie de hachage (2 160 pour SHA-1), mais seulement le espace de mot de passe, qui est beaucoup plus petit (selon votre mot de passe règles - et souvent les dictionnaires aident). Ainsi, nous ne voulons pas de rapide fonction de hachage, mais un lent. BCRYPT et vos amis sont conçus pour Ceci.
Et question similaire a ces réponses: La question est de "protéger contre les percées cryptanalytiques: combinant plusieurs fonctions de hachage" Réponse de Thomas Pornin :
combinaison est ce que SSL / TLS fait avec MD5 et SHA-1, dans sa Définition de son "PRF" interne (qui est en fait un Dérivation de la clé Fonction ). Pour une fonction de hachage donnée, TLS définit un KDF qui s'appuie sur HMAC qui repose sur la fonction Hash. Alors le KDF est invoqué deux fois, une fois avec MD5 et une fois avec SHA-1, et les résultats sont Xored ensemble. L'idée était de résister aux pauses cryptanytiques dans MD5 ou SHA-1. Notez que xoring les sorties de deux fonctions de hachage s'appuie sur des hypothèses subtiles. Par exemple, si je définis SHB-256 ( m ) = SHA-256 ( m ) xor c , pour une constante fixe c , alors SHB-256 est comme bonne fonction de hachage en tant que SHA-256; Mais le XOR des deux rendement toujours c , ce qui n'est pas bon du tout à des fins de hachage. D'où le construction en TLS dans pas vraiment sanctionné par l'autorité de Science (cela arrive-t-il juste de ne pas avoir été brisé). TLS-1.2 fait ne pas utiliser cette combinaison plus; Il repose sur le KDF avec un seul, fonction de hachage configurable, souvent SHA-256 (qui est, en 2011, un intelligent choix).
Comme @pulpspy fait remarquer, la concaténation n'est pas une bonne façon générique de fonctions de hachage de construction. Ceci a été publié par Joux en 2004, puis généralisé par Hoch et Shamir en 2006 , pour un grande classe de Construction impliquant des itérations et des concatuations. Mais l'esprit le Fine Print: Cela ne concerne pas vraiment les faiblesses survivantes dans le hachage fonctions, mais à propos de l'argent de votre argent. À savoir si vous prenez un fonction de hachage avec une sortie de 128 bits et une autre avec une sortie de 160 bits, et concaténer les résultats, la résistance de la collision ne sera pas non pire que le plus fort des deux; Ce que Joux a montré est que ce sera ne pas être beaucoup mieux non plus non plus. Avec 128 + 160 = 288 bits de sortie, vous pourrait viser 2 144 résistance, mais le résultat de Joux implique que vous n'irez pas au-delà de 2 87 .
La question devient donc: y a-t-il un moyen, si possible un efficace manière, combinant deux fonctions de hachage de telle sorte que le résultat soit comme résistant aux collisions comme le plus fort des deux, mais sans encourir L'élargissement de la production de la concaténation? En 2006, Boneh et Boyen a publié un résultat qui indique simplement que la réponse est non, sous réserve de la condition d'évaluer chaque fonction de hachage uniquement une fois que. edit: Pietrzak levé la dernière condition en 2007 (c'est-à-dire invoquer chaque fonction de hachage à plusieurs reprises n'aide pas).
et par pulpspy :
Je suis sûr que @Thomas donnera une réponse approfondie. Dans l'interm, je vais juste souligner que la résistance à la collision de votre première construction, H1 (m) || H2 (M) est étonnamment pas si mieux que le H1 (M). Voir Section 4 de ce document:
http: // Web. cecs.pdx.edu/~teshrim/spring06/papers/general-attacks/multi-joux.pdf
Regardez les réponses à Cette question .
Hachage! = Cryptage