MD5 est-il moins sécurisé que SHA et. Al. dans un sens pratique?

J'ai vu un quelques questions et réponses sur DONC, ce qui suggère que MD5 est moins sûr que quelque chose comme SHA.

Ma question est, Est-ce la peine de s'inquiéter au sujet de ma situation?

Voici un exemple de comment je l'utilise:

  1. Sur le côté client, je suis en fournissant une "sécurisé" somme de contrôle d'un message en ajoutant l'heure actuelle et un mot de passe, puis hacher à l'aide de MD5. Donc: MD5(message+time+password).
  2. Sur le côté serveur, je vérifie ce hachage contre le message qui est envoyé à l'aide de mes connaissances de l'époque, il a été envoyé et le mot de passe du client.

Dans cet exemple, suis-je vraiment intérêt à l'aide de SHA au lieu de MD5?

Dans quelles circonstances le choix de la fonction de hachage vraiment question dans un sens pratique?

Edit:

Juste pour clarifier - dans mon exempleest-il une prestation de déménagement à un algorithme SHA?

En d'autres termes, est-il possible dans cet exemple, pour quelqu'un d'envoyer un message et un bon hachage sans connaître le mot de passe partagé?

Plus Des Modifications:

Excuses répétées d'édition - je n'étais pas clair avec ce que je leur demandais.

source d'informationauteur Damovisa

  1. 29

    Oui, il vaut la peine de s'inquiéter dans la pratique. MD5 est tellement mal cassé, les chercheurs ont été en mesure de forger de faux certificats qui correspondait à un réel certificat signé par une autorité de certification. Ce qui signifie qu'ils ont été en mesure de créer leurs propres faux certificat de l'autorité, et donc pourrait usurper l'identité de toute banque ou l'entreprise qu'ils se sentaient comme avec les navigateurs complètement de leur faire confiance.

    Maintenant, cela a pris beaucoup de temps et d'effort à l'aide d'un cluster de la PlayStation 3, et de plusieurs semaines afin de trouver une collision. Mais une fois que cassé, un algorithme de hachage ne fait que s'aggraver, jamais mieux. Si vous avez des soins à tous sur la sécurité, il serait préférable de choisir un flux algorithme de hachage, comme l'un des SHA-2 de la famille (SHA-1 a également été affaibli, mais pas cassés aussi mal que MD5 est).

    modifier: La technique utilisée dans le lien que je vous ai fourni impliqué d'être en mesure de choisir deux arbitraire message préfixes et un suffixe commun, à partir de laquelle il pourrait générer pour chaque préfixe d'un bloc de données qui pourrait être inséré entre le préfixe et le suffixe commun, pour produire un message avec la même somme MD5 que le message construit à partir de l'autre préfixe. Je ne peux pas penser à une façon dont cette vulnérabilité pourrait être exploitée dans la situation que vous décrivez, et, en général, à l'aide d'un secure a pour l'authentification de message est plus résistant à l'attaque que de l'utiliser pour les signatures numériques, mais je ne peux penser à quelques vulnérabilités vous avez besoin pour regarder dehors pour, dont la plupart sont indépendants de la table de hachage, vous choisissez.

    1. Comme décrit, votre algorithme consiste à stocker le mot de passe en clair sur le serveur. Cela signifie que vous êtes vulnérable à toute divulgation de l'information des attaques qui pourraient être en mesure de découvrir des mots de passe sur le serveur. Vous pouvez penser que si un attaquant peut accéder à votre base de données, puis le jeu est en place, mais vos utilisateurs préféreront sans doute si même si votre serveur est compromis, que leurs mots de passe ne pas l'être. En raison de la prolifération des mots de passe en ligne, de nombreux utilisateurs utilisent le même ou similaire mots de passe pour tous les services. En outre, la divulgation d'informations attaques peut être possible, même dans les cas où l'exécution de code ou de remontée d'attaques ne sont pas.

      Vous pouvez atténuer cette attaque de stocker le mot de passe sur votre serveur haché avec un nombre aléatoire de sel; vous stocker la paire <salt,hash(password+salt)> sur le serveur, et envoyer le sel pour le client afin qu'il puisse calculer hash(password+salt) à utiliser à la place du mot de passe dans le protocole que vous mentionnez. Ce n'est pas de vous protéger contre la prochaine attaque, cependant.

    2. Si un attaquant peut renifler un message envoyé par le client, il est possible de faire un dictionnaire hors ligne d'attaque contre le mot de passe du client. La plupart des utilisateurs ont des mots de passe avec assez faible entropie, et d'un bon dictionnaire de quelques centaines de milliers de mots de passe existants en plus de certains temps de façon aléatoire permutant entre eux pourraient faire trouver un mot de passe donné les informations d'un attaquant de renifler un message assez facile.

    3. La technique que vous proposez ne pas authentifier le serveur. Je ne sais pas si c'est une application web qui vous parlez, mais si c'est le cas, quelqu'un qui peut effectuer un DNS détourner l'attaque, ou DHCP détournement sur un réseau sans fil non sécurisé, ou quoi que ce soit de la sorte, il suffit de faire une man-in-the-middle attack dans lequel ils collecter des mots de passe en texte clair à partir de vos clients.

    4. Alors que l'attaque actuelle contre MD5 ne fonctionne pas sur le protocole que vous décrivez, MD5 a été gravement compromise, et un hachage de ne jamais obtenir la plus faible, jamais plus. Voulez-vous parier que vous trouverez de nouvelles attaques qui pourraient être utilisés contre vous et aura le temps de mettre à niveau les algorithmes de hachage avant vos attaquants ont l'occasion d'exploiter? Il serait probablement plus facile de commencer avec quelque chose qui est actuellement plus forte que MD5, pour réduire vos chances d'avoir à traiter avec MD5 être rompu plus loin.

    Maintenant, si vous êtes en train de faire ce pour s'assurer de l'absence d'une forge un message d'un autre utilisateur sur un forum ou quelque chose, alors bien sûr, il est peu probable que quelqu'un va mettre du temps et des efforts pour briser le protocole que vous avez décrit. Si quelqu'un voulait vraiment usurper l'identité de quelqu'un d'autre, ils pourraient probablement juste de créer un nouveau nom d'utilisateur qui a un 0 à la place d'un O ou quelque chose d'encore plus semblable à l'aide de l'Unicode, et même pas la peine d'essayer de forger message et de casser l'algorithme de hachage.

    Si cela est utilisé pour quelque chose où la sécurité est vraiment important, alors il ne faut pas inventer votre propre système d'authentification. Utilisez simplement TLS/SSL. L'une des règles fondamentales de la cryptographie est pas d'inventer votre propre. Et puis, même pour le cas de la tribune où il n'a probablement pas beaucoup d'importance, n'est-ce pas plus facile d'utiliser quelque chose qui est prouvé sur l'étagère de roulement de votre propre?

  2. 12

    Dans ce cas particulier, je ne pense pas que le maillon le plus faible de votre application à l'aide de md5 plutôt que de sha. La manière dont md5 est "cassé", c'est que étant donné que md5(K) = V, il est possible de générer K' tels que md5(K') = V, parce que la sortie-l'espace est limité (pas parce qu'il y a toutes les astuces pour réduire l'espace de recherche). Cependant, K' n'est pas nécessairement K. Cela signifie que si vous savez md5(M+T+P) = V, vous pouvez générer des P' telle que md5(M+T+P') = V, ce faisant, une entrée valide. Toutefois, dans ce cas, le message reste le même, et P n'a pas été compromise. Si l'attaquant tente de falsifier le message M', T' timestamp, alors il est très peu probable que md5(M'+T'+P') = md5(M'+T'+P) sauf si P' = P. Dans ce cas, ils auraient brute forcé le mot de passe. Si ils ont brute forcé le mot de passe, alors cela signifie qu'il n'a pas d'importance si vous avez utilisé sha ou md5, puisque la vérification si le md5(M+T+P) = V est équivalente à vérifier si sha(M+T+P) = C. (sauf que sha peut prendre de la constante de temps plus longue à calculer, cela n'affecte pas la complexité de la force brute sur P).

    Toutefois, étant donné le choix, vous devriez vraiment juste aller de l'avant et à l'utilisation de sha. Il n'y a pas de sens de ne pas l'utiliser, sauf si il ya un inconvénient grave pour l'utiliser.

    Une deuxième chose, c'est que vous ne devriez probablement pas stocker le mot de passe d'utilisateur de votre base de données en texte brut. Ce que vous devez est un magasin de hachage du mot de passe, et ensuite l'utiliser. Dans votre exemple, le hash serait de: md5(message + temps + md5(mot de passe)), et vous pouvez stocker en toute sécurité md5(mot de passe) dans votre base de données. Cependant, un attaquant de voler votre base de données (par le biais de quelque chose comme l'injection SQL) serait encore en mesure de forger des messages. Je ne vois pas de moyen de contourner cela.

  3. 8

    De Brian réponse porte sur les questions, mais je pense qu'il faut expliquer un peu moins avec beaucoup de détails

    Vous utilisez le mauvais algorithme de chiffrement ici

    MD5 qui est faux ici, Sha1 est mal d'utiliser ici Sha2xx est mal d'utiliser et de l'Écheveau est mal d'utiliser.

    Ce que vous devez utiliser est quelque chose comme RSA.

    Laissez-moi vous expliquer:

    Votre secure hash est effectivement envoyer le mot de passe pour le monde à voir.

    Vous mentionnez que votre valeur de hachage est "temps + charge + mot de passe", si un tiers obtient une copie de votre charge et sait le temps. Il peut trouver le mot de passe (à l'aide d'une attaque par force brute ou par dictionnaire attaque). Donc, c'est presque comme si vous êtes à envoyer le mot de passe en texte clair.

    Au lieu de cela, vous devriez regarder un la cryptographie à clé publique votre serveur d'envoyer les clés publiques de vos agents et ont les agents de chiffrer les données avec la clé publique.

    Pas de l'homme dans le milieu seront en mesure de dire ce qui est dans les messages, et personne ne sera en mesure de forger les messages.

    Sur une note de côté, MD5 est beaucoup fort la plupart du temps.

  4. 5

    Il dépend de la valeur que le contenu des messages. Le SHA de la famille est manifestement plus sécurisé que MD5 (où "plus sécurisé" signifie "plus difficile" faux), mais si vos messages sont mises à jour twitter, alors vous avez probablement n'avez pas de soins.

    Si ces messages sont la CIB couche d'un système distribué qui gère les transactions financières, alors peut-être que vous vous souciez plus.

    Mise à jour: j'ajoute, également, que les deux algorithmes digest sont essentiellement interchangeables dans de nombreuses façons, alors, comment beaucoup plus de mal serait-il vraiment à utiliser le plus sécurisé?

    Mise à jour 2: c'est beaucoup plus approfondie réponse: http://www.schneier.com/essay-074.html

  5. 2

    Oui, quelqu'un peut envoyer un message et un bon hachage sans connaître le mot de passe partagé. Ils ont juste besoin de trouver une chaîne qui hachages pour la même valeur.

    Comment est-ce? En 2007, un groupe de pays-bas ont annoncé qu'ils avaient prédit le vainqueur de l'élection Présidentielle AMÉRICAINE de 2008 dans un fichier avec le hash MD5 de la valeur 3D515DEAD7AA16560ABA3E9DF05CBC80. Ils ont ensuite créé douze des fichiers, tous identiques, sauf pour le nom d'un candidat et un nombre arbitraire d'espaces suivants, qui haché à cette valeur. La valeur de hachage MD5 est sans valeur comme une somme de contrôle, car un trop grand nombre de fichiers différents donnent le même résultat.

    C'est le même scénario que le vôtre, si je suis en train de lire vous droit. Il suffit de remplacer "nom du candidat" avec "mot de passe secret". Si vous voulez vraiment être sûr, vous devriez probablement utiliser une autre fonction de hachage.

  6. 1

    si vous allez générer un hachage-mac n'inventez pas de votre régime. utilisation HMAC. il y a des problèmes avec le fait de HASH(clé secrète || message) et DIÈSE(message || secret-key). si vous utilisez un mot de passe comme clé, vous devez également être à l'aide d'une fonction de dérivation de clé. jetez un oeil à pbkdf2.

  7. 1

    Oui, il vaut la peine de se soucier de hachage à utiliser dans ce cas. Regardons le modèle d'attaque en premier. Un attaquant peut ne pas essayer de générer des valeurs md5(M+T+P), mais peut aussi essayer de trouver le mot de passe de P. En particulier, si l'attaquant de collecter tupels de valeurs de MiTiet le md5 correspondant(MiTiP) ensuite, il/elle pourrait essayer de trouver des P. Ce problème n'a pas été étudié de manière aussi complète pour les fonctions de hachage que de trouver des collisions. Mon approche à ce problème serait d'essayer les mêmes types d'attaques qui sont utilisés contre les algorithmes de chiffrement par bloc: différentielles, par exemple les attaques. Et depuis MD5 déjà très sensibles à la différence des attaques, je peux certainement imaginer qu'une telle attaque pourrait être couronnée de succès ici.

    Donc je recommande que vous utilisez une plus forte fonction de hachage que MD5 ici. Je vous conseille également d'utiliser l'algorithme HMAC au lieu de simplement md5(M+T+P), parce que HMAC a été conçu pour la situation que vous décrivez et a donc été analysé.

  8. 0

    Il n'y a rien d'insécurité sur l'utilisation de MD5 de cette manière. MD5 n'est brisé dans le sens où, il y a des algorithmes qui, étant donné un tas de données supplémentaires données B peuvent être générés pour créer souhaité de hachage. Sens, si quelqu'un connaît la valeur de hachage d'un mot de passe, ils peuvent produire une chaîne de caractères résultat avec celui de hachage. Cependant, ces généré chaînes sont généralement très longs donc, si vous limitez les mots de passe à 20 ou 30 caractères, vous êtes probablement encore sûr.

    La raison principale de l'utilisation de SHA1 sur MD5, c'est que MD5 fonctions sont en cours de suppression. Par exemple, le Silverlight .Net de bibliothèque n'a pas d'inclure le MD5 de la cryptographie fournisseur.

  9. 0

    MD5 fournir plus de collisions que SHA, ce qui signifie que quelqu'un peut réellement obtenir la même valeur de hachage à partir de différents mots (mais rarement).

    SHA de la famille a été connu pour sa fiabilité, SHA1 a été la norme sur l'utilisation quotidienne, tout en SHA256/SHA512 a été une norme pour le gouvernement et la banque appareils.

    Pour votre site web personnel ou d'un forum, je vous suggère de considérer SHA1, et si vous créez un plus sérieux comme le commerce, je vous suggère d'utiliser SHA256/SHA512 SHA2 (famille)

    Vous pouvez consulter l'article de wikipedia sur MD5 & SHA

  10. 0

    À la fois MD5 amd SHA-1 ont des faiblesses cryptographiques. MD4 et SHA-0 sont également compromise.

    Vous pouvez probablement utiliser en toute sécurité MD6, bain à Remous, et RIPEMD-160.

    Voir le powerpoint (en anglais) de l'Université de Princeton, faites défiler jusqu'à la dernière page.

    http://gcu.googlecode.com/files/11Hashing.pdf

  11. 0

    Je ne vais pas commenter le MD5/SHA1/etc. problème, alors peut-être vous verrez que cette réponse est discutable, mais quelque chose qui m'amuse très légèrement est à chaque fois que l'utilisation de MD5 et coll. pour le hachage des mots de passe dans les bases de données.

    Si quelqu'un fouiller dans votre base de données, alors qu'ils pourraient très bien vouloir regarder vos mots de passe, mais il est tout aussi probable qu'ils vont vouloir voler des informations personnelles ou autres données que vous avez qui traînent dans les autres tables. Franchement, dans cette situation, vous avez de plus gros poissons à frire.

    Je ne dis pas ignorer le problème, et comme je l'ai dit, ce n'est pas vraiment beaucoup d'influence sur si oui ou non vous devez utiliser MD5, SHA1 ou que ce soit pour hacher vos mots de passe, mais je ne reçois chatouillait légèrement rose chaque fois que je lis quelqu'un un peu trop bouleversé texte en clair les mots de passe dans une base de données.