md5($password.md5($password)) is this good enough for password hashing? I am not asking for comparing this to something like bcrypt.if it is not secure, tell me why.
6 Réponses :
Il ne fait pas beaucoup d'attaques de dictionnaire, seulement deux fois plus difficile à calculer un dictionnaire par rapport à un seul MD5 , et MD5 est assez bon marché.
pas vraiment. Ce n'est pas plus difficile de calculer le dictionnaire avec un sel fixe ou votre méthode. même complexité.
La même chose va pour le sel aléatoire, n'est-ce pas?
@Col. Shrapnel: Non, car vous devriez alors essayer chaque mot contre le sel unique, par mot de passe, ce qui en fait un jeu beaucoup plus intensif de main-d'œuvre. Avec un seul sel connu, vous devrez seulement créer un dictionnaire une fois.
Mais ce n'est pas célèbre sel connu. Tous ces sels sont différents!
@Col. Shrapnel: Je pense qu'il y a une mauvaise communication ici. Vous avez peut-être mal compris moi. Je pense que nous parlons de la même chose. Sel simple connu pour tous les mots de passe = pire. Sel unique par mot de passe = mieux.
La raison d'utiliser un sel différent pour chaque mot de passe de l'utilisateur est de sorte qu'un attaquant ne peut pas prendre une liste de tous les mots de passe hachés et voir si l'un d'entre eux correspondent au hasch de quelque chose de facile comme "mot de passe" ou "12345" . Si vous deviez utiliser le mot de passe lui-même comme sel, un attaquant peut calculer Si je comprends bien, il y a quatre niveaux de hachage que vous pouvez utiliser sur une table de mot de passe:
Pour plus de détails, consultez le message d'horreur de codage, " Vous stockez probablement probablement des mots de passe de manière incorrecte ". MD5 ("12345" .md5 ("12345")) et voir s'il correspondait à toutes les entrées.
En cas de sel aléatoire, ce qui empêche un attaquant de calculer MD5 ("12345" .md5 ("54321random")) ?
Quelle partie de votre réponse appartient à l'OP en particulier?
À mon avis, @Col. La technique suggérée de l'OP de MD5 ($ mot de passe.md5 ($ mot de passe)) est approximativement aussi difficile à casser que mon option 3, mais plus chère pour le serveur, car il nécessite deux calculs MD5 pour chaque connexion . Je pense que c'est aussi difficile de casser l'option 3 car un attaquant qui connaît l'algorithme peut calculer un hash pour un mot de passe faible, puis le comparer au mot de passe haché de chaque utilisateur.
Je ne suis pas sûr de ce que vous demandez à l'attaquant calculant dans votre premier commentaire, @Col. Si vous demandez une option 3 plus difficile à casser que l'option 2, il s'agit simplement de cette option 2 peut être attaquée par des tables arc-en-ciel précalculées et ne nécessite pas autant de travail de l'attaquant.
Donc, vous parlez de coïncidence de certains mots de passe boiteux, non?
Je ne suis pas tout à fait sûr de ce que vous entendez par "coïncidence de certains mots de passe boiteux", @Col. Je suppose qu'un attaquant a accès à toutes les informations sur le système, à l'exception des mots de passe d'utilisateur réels. De plus, une liste des milliards de mots de passe les plus probables triés par fréquence et une table arc-en-ciel préalculée pour les millions de mots de passe les plus probables. Aucune des possibilités que j'ai définies empêche d'extraire l'un des mots de passe, mais chacun augmente le temps de traitement requis pour l'attaquant de trouver un mot de passe.
@Col: Vous devez seler vos mots de passe, et il devrait être avec une valeur distincte qui est stockée dans ClearText ou dans le cadre de la valeur hachée. Je ne sais pas quel est votre problème ici.
@Adam je n'ai pas un seul problème. C'est Don qui l'a.
@Don Kirby, "Temps de traitement" n'est pas vraiment un accord énorme pour gérer une transaction comme la journalisation. Ce qui ne se produit pas souvent cela pour commencer. En fait, cette publication mentionne des avantages intéressants pour avoir une durée d'authentification plus longue.
Merci pour le lien, @kenny. Lorsque j'ai dit de temps de traitement, je faisais référence au temps de traitement de l'attaquant, pas au serveur qui fait l'authentification. Mais votre point sur les avantages d'un algorithme de cryptage coûteux est un bon.
La raison pour laquelle le sel de mot de passe aléatoire est recommandé pour le mot de passe de hachage, de sorte qu'un attaquant qui connaisse le mot de passe hachage ne peut pas le comparer à Si vous utilisez un mot de passe comme sel, l'attaquant peut préciser les hachages de $ Word.MD5 ($ Word) d'abord de leur dictionnaire
Quelle est la différence entre ce pré-calcul et le calcul lui-même?
Avec votre solution, vous défait à peu près le but d'utiliser un sel contre des attaques de dictionnaires précomptes.
avec un dictionnaire précalculé, comme le nom l'indique, une personne a déjà créé une table de hachage (le Considérez ce tableau MD5 Résultat) Pour des mots particuliers, à l'avance. p> HASHTABLE code> (avec des hachages imaginaires, juste à des fins d'illustration) p> md5( 'uniquesalt' . 'password' );
Votre requête est la même que de calculer un hachage pour chaque variante possible. Comment ça va différer de la force brute?
@Col. Shrapnel: Vous avez du bon point là-bas. Certes n'est pas très différent, sauf que vous n'avez pas à hacher deux fois, ce qui vous gagnerait probablement un peu de temps. Pas beaucoup peut-être. Mais mon point principal était d'illustrer qu'une table précalisée ne considère généralement généralement que des mots simples. Et ne prend pas en compte des mots concatérés qui sont hachés.
Bien que cela me semble assez assez, il sera en danger si quelqu'un préconcule une table arc-en-ciel basée sur le même algorithme (ce qui est tout à fait possible).
Donc, je préférerais utiliser un email pour le sel qui semble assez sécurisé mais utilisable. Les paranoïaques peuvent ajouter un sel constant à l'échelle du site.
Les gens rendent souvent trop gros problème du sel de mot de passe (en théorie), tandis que dans leurs applications, ils permettent de simples mots de passe et de les transférer en texte brut sur l'insécurité HTTP dans la pratique.
Chaque jour de Freakin 'Je vois des questions concernant le sel ou le hash. pourquoi? Laisse moi te montrer.
Bon sel extraordinaire + Mot de passe faible = brisable en secondes
On suppose toujours que le sel est connu de l'attaquant. Ainsi, en utilisant un dictionnaire des mots de passe les plus utilisés et en ajoutant [quel que soit le sel supplémentaire-aléatoire-super], un mot de passe faible peut être découvert en quelques secondes. Idée va pour les mots de passe courts brute-forcer.
juste sel sensible + mot de passe fort = incassable
Sel assez unique fait des tables précalisées inutiles et bon mot de passe de dictionnaire et de forces de brute bien pour rien.
Et pas une seule en ce qui concerne la complexité de mot de passe. Tandis que
La seule votre préoccupation devrait être une complexité de mot de passe.
@Col. Shrapnel: Concernant votre dernière remarque: Bon point. Mais intercepter un seul mot de passe n'est guère aussi problématique que d'obtenir toute la table. Sauf si bien sûr, la renifleuse n'écoute aux portes, à condition que les utilisateurs de coïncidence se terminent.
Le sel aléatoire est le moyen d'aller et utilisé par le plus digne système de gestion de mots de passe. Un sel aléatoire simple simple fait de la table arc-en-ciel 65536 fois plus cher à calculer et à stocker ...
@Bruno Le sel proposé par l'OP est de 128 bits assez aléatoires. Qu'est ce qui ne va pas avec ça? Qu'est-ce que en particulier faux?
L'OP propose une latte dépendante du mot de passe, pas aléatoire. Ce n'est en fait pas un sel du tout. Dites que je veux stocker tout le hash pour 4 lettres de passe de lettres minuscules: sa proposition ne me coûte que 4 ^ 26 * 128 bits car chaque mot de passe ne peut que conduire à un hachage. Avec une graine de 16 bits, cela me coûterait 2 ^ 16 autant d'espace disque que chaque mot de passe de l'utilisateur peut maintenant avoir 2 ^ 16 hachage le représentant. Aller au sel de 32 bits, vous fabriquez des tables arc-en-ciel presque impossibles à stocker et très longtemps pour calculer même de jeter beaucoup de matériel au problème.
@Bruno C'est en effet un sel, même étant aussi aléatoire. Avec un bon mot de passe fort, il sera suffisant avec un mot de passe faible sans sel super-extra-aléatoire aidera à l'encontre du dictionnaire / de la force brute.
Ce n'est pas dans son schéma, il existe une relation 1 <-> 1 entre les mots de passe et leur représentation de disque. Avec un sel aléatoire avec N sels possibles, il existe une relation de 1 <-> N entre des mots de passe et leur représentation de disque, ce qui le rend beaucoup plus coûteux pour pré-calculer les hachés.
@Bruno Vous parlez de mots de passe coïncidents?
MD5 n'est pas sécurisé en soi car il est partiellement brisé (collisions) et est trop petit d'un digest. Si on ne veut pas utiliser une fonction de dérivation de mot de passe appropriée à la bcrypt, scypt ou PBKDF2 vous devrait au moins utiliser SHA-256 pour de nouvelles conceptions (et avoir un plan de migration vers SHA-3 lorsqu'il s'agira, assurez-vous de stocker le schéma que vous avez utilisé pour hacher le mot de passe avec le résultat. Les deux systèmes peuvent donc coexister comme Vous utilisez la nouvelle procédure de hachage lorsque les gens changent de mots de passe).
Si vous avez l'intention de vendre votre programme à l'aide de MD5 à n'importe quelle capacité peut être un bouchon d'affichage pour la plupart des ventes gouvernementales (par exemple, dans les algorithmes américains utilisés doivent être approuvés 140-2 approuvés et de nombreux autres pays ont obtenu le même type d'exigences).
J'étais toujours curieux, quelles collosions peuvent faire avec des mots de passe salés? (Si vous en trouvez même un)
Rien d'un point de vue de la connaissance actuel. Les attaques de collision ne traduisent pas nécessairement comme une attaque pré-image, mais leur simple existence montrent que la conception est cassée. Une partie du contrat d'une fonction de hachage cryptographique est cassée, vous ne pouvez plus la faire confiance. Continuer à utiliser MD5 est comme boire dans un verre avec une fissure, vous pouvez être parfaitement correct, mais cela pourrait également vous briser dans votre main vous envoyer à la salle d'urgence.
Je peux imaginer scénario de verre brisé. Mais je n'ai aucune idée du scénario particulier peut être en cas de conduite de hachage. Pouvez-vous élaborer un peu? Ou vous ne savez pas mais que vous êtes prudent juste au cas où?
CANAUX Juste au cas où, vous avez une collection de lunettes, pourquoi boire dans l'une avec une fissure quand un chiffre immaculé est à côté de celui-ci. La confiance dans un hachage cryptographique est brisée au moment où une seule attaque pratique est trouvée. Et franchement, la commutation d'algorithme de hachage est généralement une question de changement d'un appel, alors pourquoi aller avec l'option moindre?
Juste pour être un programmeur, pas adorateur. Être un programmeur, je veux comprendre ce qui est particulièrement faux avec mon verre.
MD5 ($ mot de passe.md5 ($ id)) est meilleur?Oui, @wiiman, en utilisant l'identifiant de l'utilisateur car le sel est bien meilleur. Je vais développer ma réponse un peu.
Voir également l'openwall's Cadre de hachage de mot de passe PHP (PHPASS). Son portable et durcit contre un certain nombre d'attaques communes sur les mots de passe utilisateur. Le gars qui a écrit le framework (Solardesigner) est le même gars qui a écrit John the Ripper et est assis comme Un juge dans le Concours de hachage de mot de passe . Donc, il connaît une chose ou deux sur des attaques sur les mots de passe.