Pourquoi ne pas utiliser MD5 pour le hachage de mot de passe?

J'ai un ami qui est un white hat hacker. Il dit que le md5 n'est pas vraiment mauvais, et c'est vraiment sécurisé, seulement si nous l'utilisons correctement.

Je crois qu'il est à droite. Que je sache, il y a 3 façons de se débarrasser de hachages:

  1. À l'aide de tables arc-en-ciel (Qui peut être obtenu par une longue/aléatoire sel)
  2. Collision (Qui peut être évité par plusieurs sels ou des hachages - comme dans l'exemple ci-dessous)
  3. Temps de génération (Qui n'est pas très important si l'on utilise un assez long sel de la valeur pour chaque utilisateur, autant que je sache)

Moi et mon ami crois que Blowfish n'est pas vraiment besoin, il peut aussi être dangereux car il peut ralentir le processus de validation de mot de passe et il peut être utilisé avec des attaques DDOS à briser serveur, même avec moins de attak-ressources.

Donc, je veux vous assurer que c'est la suite de l'algorithme de vraiment sécurisé ou pas? Et, est-il une raison d'y aller avec Blowfish algorithme de hachage ou pas?

//return a 256 bit salt + 128 bit md5 binary hash value
function hash(password, salt=null)
{
    salt = (salt != null) ? salt : Random256BitBinaryValueGenerator();
    //What about using another user-specified parameter, like email address as salt?

    return salt + md5(salt + password) + md5(password + salt);

    //Or just use a non-cryptographic hash algorithm like crc32 to prevent collisions:
    //return salt + md5(salt + password) + crc32(salt + password);

    //Or even use two different salts:
    //return salt + md5(salt + password) + md5('C' + salt + password);
}

//check password
function check(password, hash_value)
{
    return hash(password, substring(hash_value, 0, 32)) == hash_value;
}
MD5 est connu pour ne pas être résistant à la collision depuis 1996, etconsidéré du point de vue cryptographique cassé et inutilisable" quoi de plus avez-vous besoin? Pourquoi serait-on insister à l'aide d'un morceau de crypto quand SHA2 est facilement disponible?
Je sais que SHA2 est sécurisé, ou Blowfish est encore plus sûr, mais je veux savoir la vraie raison pour aller avec ces algorithmes plus récents, je veux dire, si nous pouvons faire md5 sûr, pourquoi aller avec un autre algorithme? Selon le lien suivant, la probabilité de seulement deux hachages accidentellement en collision est (1/2)^128, donc md5(s+p) + md5(p+s) la probabilité de collision est (1/2)^256, ce qui est très sécuritaire, à mon avis, même pour la sécurité des applications exigeantes lorsqu'il est combiné avec un nombre aléatoire de sel. stackoverflow.com/questions/201705/...
Aussi, comme je le sais, car de longueur fixe de hashs sorties, il n'est pas exempt de collision algorithme de là-bas, donc, si nous n'avons pas trouver toutes les collisions dans sha2 pourtant, cela ne signifie pas que sha2 est sûr (ce qui n'est pas parce que ce que j'ai dit). Alors, pourquoi aller avec sha2 lorsque nous pouvons obtenir md5? (Si c'est possible?)
Ce que vous voulez est bcrypt, pas blowfish.
bcrypt est basé sur blowfish.

OriginalL'auteur Masoud | 2015-05-28

  1. 14

    La la collision de la résistance propriété de MD5 a été rompu pour un long moment. Notez que le preimage résistance et deuxième preimage de la résistance n'ont pas encore été fissuré, cependant, comme il y a de meilleurs algorithmes (SHA-2), il serait sage de les déplacer à ces plutôt que de compter sur un hachage cryptographique qui a déjà commencé à perdre ses propriétés cryptographiques. Remarque: La collision propriété de résistance à la n'a pas d'importance lors du stockage des mots de passe hachés - ce que vous avez besoin pour vous assurer c'est que le preimage propriété de résistance est sonore qu'il est mathématiquement impossible de trouver le mot de passe original a partir d'une certaine valeur de hachage (et le sel). Comme je l'ai mentionné, car l'une des propriétés cryptographiques est déjà cassé, je serais inquiète de ce que les autres vont bientôt suivre.

    Lorsque vous stockez un hachage de mot de passe, vous devez construire dans une certaine protection qu'à l'origine le mot de passe ne peut être retrouvé, dans le cas où un attaquant parvient à extraire ces valeurs de hachage. Ceci est important parce que si un attaquant parvient à récupérer le mot de passe de la table seulement ils peuvent ensuite utiliser les données permettant de vous connecter à votre système directement, ou pour vous connecter à d'autres systèmes où l'utilisateur a réutilisé le même mot de passe.

    Lors du stockage des mots de passe, il est important d'utiliser un lent algorithme, comme bcrypt, scrypt ou pbkdf2. Un utilisateur légitime ne devrait avoir à l'expérience du retard une fois, lors de la première connexion. Un attaquant aurez l'expérience de la de retard pour chaque mot de passe qu'ils devinent - souvenez-vous de "rainbow tables" ne sera pas utilisé ici, car les mots de passe sont salés. L'attaquant sera le hachage de mot de passe guess en ligne avec l'algorithme choisi et le nombre d'itérations.

    Il est important de régler le nombre d'itérations pour votre système de sorte que le droit de "force" est utilisé non pas pour cause légitime, les utilisateurs réelle gêne lors de la connexion à votre système. Ceci est connu comme le nombre de "tours" ou le "nombre d'itérations". Par exemple, le parcours pendant environ une seconde devrait être suffisant. Il peut être prudent de supposer qu'un attaquant peut fonctionner à travers les hachages à dix fois la vitesse du matériel de votre système. Par conséquent, ce qui limite l'attaquant de 10 essais par seconde, au lieu de deux milliards de dollars, avec MD5.

    Concernant les attaques DoS

    Oui, le supplément de traitement de votre application effectue jusqu'à la connexion pourrait être une cible pour un attaquant de présenter soit vraiment long les mots de passe à votre demande, ou à frappé à plusieurs reprises avec les requêtes de connexion afin de consommer du CPU et de la mémoire de ressources sur votre serveur. Vous êtes en droit d'être inquiets.

    Ces types d'attaques peuvent être atténués de l'une des manières suivantes:

    • Journal le nom d'utilisateur et l'adresse IP de chaque tentative de connexion. Après dire 6 tentatives infructueuses, introduire un délai dans la réponse à partir de votre application si ce nom d'utilisateur ou adresse IP est répété à nouveau. Cela contribuera également à réduire deviner les mots de passe des attaques en général.
      • Par exemple, vous pourriez artificiellement délai de 1 seconde, 2 secondes, puis 4 et jusqu'à une valeur raisonnable (par exemple, 16 secondes).
      • Ceci a l'avantage que l'attaquant ne peut pas verrouiller un autre compte sur le but que l'utilisateur légitime a plus qu'à attendre de 16 secondes.
      • Un attaquant pourrait utiliser un botnet et au hasard les noms d'utilisateur de contourner ces contrôles, mais ils auraient besoin d'un grand nombre d'adresses IP que sans ce contrôle, et plus décontracté attaquant aussi de ne pas être au courant que le retard dans la réponse était artificielle.
    • Surveiller le nombre de tentatives de connexion sur votre système. Une fois que cela est au-dessus d'un seuil fixé de taux (par exemple 10 par seconde), mettre en place un CAPTCHA à résoudre pour continuer le processus de connexion. Le taux de seuil que vous choisissez dépend beaucoup de l'utilisateur de la base et la capacité de votre système.
    • Mettre en œuvre l'authentification à deux facteurs. Seulement procéder à la validation de mot de passe par hachage une fois le Mot de passe a été validé.
    SilverlightFox, À mon avis, une lente algorithme n'est pas très sécurisé. J'ai 2 raisons, l'une est expliqué dans la question (DDOS) et un autre est commenté en @martinstoeckli réponse. Pouvez vous s'il vous plaît vérifier ces et dites-moi si je me trompe ou pas?
    Réponse de mise à jour. Quelle est la deuxième cause?
    Raison numéro 2: En utilisant le GPU, on peut calculer environ 8,5 milliards de hachages par seconde. Avec 10 caractères de longueur de mot de passe (contenant de a-z, A-Z et de 0 à 9 caractères), nous pouvons briser dans 13714 heures en moyenne, même avec ce logiciel, et avec un 12 caractères des mots de passe, il a besoin de 6000 ans en moyenne juste pour partager une même valeur de hachage. N'est-il pas suffisant? ((26+26+10)^12/(8.5*10^9) / 60/60/24/365 / 2=6017 ans) N'est-il pas préférable de forcer l'utilisateur à choisir un meilleur mot de passe avec une meilleure puissance, au lieu d'utiliser plus complexes algorithmes de hachage? n'est-ce pas les algorithmes de devenir un autre md5 dans le futur bientôt, basé sur la loi de moore?
    Aussi, je vous remercie pour ces très bons conseils. J'ai utilisé tous les d'eux, mais de façons différentes. J'ai mis un retard constant de 2 secondes, toutes les tentatives de connexion et après 2 secondes, j'ai vérifier l'état de la connexion pour voir si l'utilisateur est en attente de réponse ou la connexion est abandonnée. Et je vous présenter le captcha après chaque échec de tentatives de connexion par IP. Qui vos suggestions, c'est beaucoup mieux que ma façon.
    Rappelez-vous, force du mot de passe n'est pas un vrai métrique - cela dépend des sources d'entropie effectivement utilisés. Oui une clés d'attaque sur un de 10 char mot de passe peut prendre 517 jours, cependant, si vous savez que l'utilisateur n'a pas choisi vraiment un mot de passe aléatoire que l'homme ne sont pas aléatoires alors, pratiquement, il ne prendra pas 517 jours. Vous ne pouvez pas jamais forcer l'utilisateur à créer un mot de passe aléatoire, sauf si vous spécifiez vous - même, et qui a ses propres problèmes.

    OriginalL'auteur SilverlightFox

  2. 5

    Le problème avec MD5 est exactement ce que ce est si rapide, vous pouvez calculer sur 9 Giga MD5/s avec le matériel courant. Par la force brute d'un ensemble de dictionnaire d'anglais avec environ 200000 mots, vous avez besoin seulement une fraction d'une milli-seconde.

    C'est pourquoi approprié algorithmes de hachage comme BCrypt offre un facteur de coût. Le facteur de coût définit la façon dont beaucoup de temps est nécessaire pour calculer le hash et peut être augmentation du dans le futur. 50 millisecondes pour une connexion n'est pas un obstacle, mais pour brute-forcer c'est mortel.

    J'ai toujours pensé que nous pouvons apporter quelques milliers md5s/s, même avec un bon cpu. Mais 9 Giga MD5/s est vraiment fou!!!
    C'est vraiment un nombre impressionnant, notez que le lié logiciel utilise le GPU pas le CPU. Mais néanmoins, tout le monde peut acheter pas cher Gpu et le départ de la course...
    Consultez également les dérivations (juste quelques lignes ci-dessus sur la page du lien). Là vous pouvez voir que cracker outils offrent beaucoup de combinaisons possibles, comme md5($salt.$pass.$salt) hors de la boîte.
    Ouais. Avec un ~$200 gpu, on peut calculer environ 8,5 milliards de hachages par seconde. Avec 10 caractères de longueur de mot de passe (contenant de a-z, A-Z et de 0 à 9 caractères), nous pouvons briser dans 13714 heures en moyenne, même avec ce logiciel, et avec un mot de passe de 12 caractères, il a besoin de 6000 ans en moyenne juste pour partager une même valeur de hachage. N'est-il pas suffisant? ((26+26+10)^12/(8.5*10^9) / 60 / 60 / 24 / 365 / 2 = 6017 ans) N'est-il pas préférable de forcer l'utilisateur à choisir un meilleur mot de passe avec une meilleure puissance, au lieu d'utiliser plus complexes algorithmes de hachage? n'est-ce pas les algorithmes de devenir un autre md5 dans le futur bientôt, basé sur la loi de moore?
    Une bonne question. • Pas de ne pas devenir la prochaine MD5, en raison du facteur de coûts, l'augmentation de ce facteur par 1 double du temps nécessaire pour calculer une valeur de hachage. • Et non, vous pouvez encourager les utilisateurs à utiliser des mots de passe plus forts, mais vous ne pouvez pas les forcer. Complexe de règles de mot de passe seront en conflit avec le bon mot de passe, les utilisateurs sont très inventive avec des mots de passe: Password-2015 de répondre à la plupart des règles, mais est très faible mot de passe. Même des mots de passe faibles doivent être protégés autant que possible, même si ils ne sont pas recommandés.

    OriginalL'auteur martinstoeckli

  3. 0

    Vous parler de ralentissement de la validation comme un problème, mais c'est le seul moyen de défense contre une fuite de hachage et une attaque en force brute. Des solutions modernes de hachage de la valeur à plusieurs reprises (c'est à dire: des milliers de fois) juste pour augmenter le coût du calcul.

    Neil, À mon avis, une lente algorithme n'est pas très sécurisé. J'ai 2 raisons, l'une est expliqué dans la question (DDOS) et un autre est commenté en @martinstoeckli réponse. Pouvez vous s'il vous plaît vérifier ces et dites-moi si je me trompe ou pas?
    Vous avez un lien pour le DDOS de référence?

    OriginalL'auteur Neil Smithline