MD5 est moins sûr que SHA et. Al. dans un sens pratique?

https://stackoverflow.com/questions/770900

12-09-2019
|

Question

Je l'ai vu https://stackoverflow.com/questions/116684/what-algorithm-should-i-use-to-hash-passwords-into-my-database peu questions et réponses sur ce qui suggère que SO MD5 est moins sûr que quelque chose comme SHA.

Ma question est, Est-ce vaut se soucier dans ma situation?

Voici un exemple de la façon dont je l'utilise:

Du côté client, je fournir une somme de contrôle « sécurisé » pour un message en annexant l'heure actuelle et un mot de passe et puis en utilisant le hachage MD5. Donc:. MD5(message+time+password)
Du côté du serveur, je vérifie ce hachage contre le message qui est envoyé en utilisant ma connaissance du temps qu'il a été envoyé et le mot de passe du client.

Dans cet exemple, suis-je vraiment mieux à l'aide SHA au lieu de MD5?

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

Modifier

Juste pour préciser - dans mon exemple , est-il un avantage de passer à un algorithme SHA

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

Plus Edits:

Toutes mes excuses pour l'édition répétée -. Je n'étais pas clair avec ce que je demandais

La solution

Oui, il vaut la peine se soucier dans la pratique. MD5 est tellement cassé que ont été en mesure de forger des faux certificats qui correspondent un vrai certificat signé par une autorité de certification. Cela signifie qu'ils ont pu créer leur propre autorité de certification de faux, et pourrait donc usurper l'identité d'une banque ou d'une entreprise, ils se sentaient comme avec les navigateurs complètement à leur faire confiance.

Maintenant, cela leur a fallu beaucoup de temps et d'efforts à l'aide d'un groupe de PlayStation 3, et plusieurs semaines pour trouver une collision appropriée. Mais une fois cassé, un algorithme de hachage ne fait qu'empirer, jamais mieux. Si vous vous souciez du tout sur la sécurité, il serait préférable de choisir un algorithme de hachage continu, comme l'un des SHA -2 de la famille (SHA-1 a également été affaiblie, mais pas cassé aussi mal que MD5 est).

modifier : La technique utilisée dans le lien que je vous ai exposés Impliquez pouvoir choisir deux préfixes de messages arbitraires et d'un suffixe commun, à partir duquel il pourrait générer pour chaque préfixe un bloc de données qui pourraient être insérée entre ce préfixe et le suffixe commun, pour produire un message avec la même somme de contrôle MD5 que le message construit à partir de l'autre préfixe. Je ne peux pas penser à une façon dont cette vulnérabilité particulière pourrait être exploitée dans la situation que vous décrivez, et en général, en utilisant un Secureest pour un message d'authentification est plus résistant à l'attaque que de l'utiliser pour les signatures numériques, mais je ne peux penser à quelques vulnérabilités dont vous avez besoin à surveiller, qui sont pour la plupart indépendants du hachage que vous choisissez.

Comme cela est décrit, votre algorithme consiste à stocker le mot de passe en texte clair sur le serveur. Cela signifie que vous êtes vulnérable à des attaques de divulgation de l'information qui peuvent être en mesure de découvrir les mots de passe sur le serveur. Vous pouvez penser que si un attaquant peut accéder à votre base de données, le jeu est en place, mais vos utilisateurs préféreront sans doute si, même si votre serveur est compromise, que leurs mots de passe ne soient pas. En raison de la prolifération des mots de passe en ligne, de nombreux utilisateurs utilisent les mots de passe identiques ou similaires dans les services. En outre, les attaques de divulgation d'information peut être possible, même dans les cas où les attaques d'escalade d'exécution de code ou privilège ne sont pas.

Vous pouvez atténuer cette attaque en stockant le mot de passe sur votre serveur avec un sel haché aléatoire; vous stockez la paire <salt,hash(password+salt)> sur le serveur, et d'envoyer le sel au client afin qu'il puisse calculer hash(password+salt) d'utiliser à la place du mot de passe dans le protocole que vous mentionnez. Cela ne vous protège pas contre la prochaine attaque, cependant.
Si un attaquant peut renifler un message envoyé par le client, il peut faire une attaque de dictionnaire en ligne contre le mot de passe du client. La plupart des utilisateurs ont des mots de passe avec l'entropie assez faible, et un bon dictionnaire de quelques centaines de milliers de mots de passe existants, plus un peu de temps les permutant au hasard pourraient permettre de trouver un mot de passe donné l'information un attaquant a de renifler un message assez facile.
La technique que vous proposez ne pas authentifier le serveur. Je ne sais pas si cela est une application Web qui vous parlez, mais si elle est, quelqu'un qui peut effectuer une attaque de hijack DNS ou détournement d'avion DHCP sur un réseau sans fil non sécurisé, ou quelque chose du genre, peut tout faire un homme-in-the-middle où ils recueillent des mots de passe en texte clair de vos clients.
Alors que l'attaque actuelle contre MD5 ne fonctionne pas contre le protocole que vous décrivez, MD5 a été gravement compromise, et un hachage ne jamais faiblir, jamais plus fort. Voulez-vous parier que vous découvrirez au sujet de nouvelles attaques qui pourraient être utilisées contre vous et auront le temps de mettre à jour des algorithmes de hachage avant que vos attaquants ontchance de l'exploiter? Il serait probablement plus facile de commencer par quelque chose qui est actuellement plus forte que MD5, pour réduire vos chances d'avoir à traiter avec MD5 être brisé plus loin.

Maintenant, si vous faites juste cela pour vous assurer que personne ne forge un message d'un autre utilisateur sur un forum ou quelque chose, bien sûr, il est peu probable que tout le monde va mettre le temps et les 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 créer un nouveau nom d'utilisateur qui a un 0 en place d'un O ou quelque chose d'encore plus similaire en utilisant Unicode, et même pas la peine d'essayer de forger un message et de briser des algorithmes de hachage.

Si cela est utilisé pour quelque chose où la sécurité est vraiment important, alors ne pas inventer votre propre système d'authentification. Il suffit d'utiliser TLS / SSL . L'une des règles fondamentales de la cryptographie est ne pas inventer votre propre . Et puis, même pour le cas du forum où il n'a probablement pas tant que ça, il ne sera pas plus facile à utiliser juste quelque chose qui a fait ses preuves sur l'étagère que rouler votre propre?

Autres conseils

Dans ce cas particulier, je ne pense pas que le maillon le plus faible de votre application utilise md5 plutôt que sha. La manière dont md5 est « cassé » est que, étant donné que md5 (K) = V, il est possible de générer K « tel que md5 (K ») = V, parce que l'espace de sortie est limitée (pas parce qu'il y en a astuces pour réduire l'espace de recherche). Cependant, K 'est pas nécessairement K. Cela signifie que si vous connaissez md5 (M + T + P) = V, vous pouvez générer P' tel que md5 (M + T + P ') = V, ce donnant une entrée valide . Toutefois, dans ce cas, le message reste toujours le même, et P n'a pas été compromise. Si l'attaquant tente de forger un message M 'avec un T' horodatage, alors il est très peu probable que md5 (M '+ T' + P ') = md5 (M' + T '+ P) à moins que P' = p dans ce cas, ils auraient brute forçaient le mot de passe. S'ils ont forcé le brute-mot de passe, cela signifie qu'il n'a pas d'importance si vous avez utilisé sha ou md5, car vérifier si md5 (M + T + P) = V équivaut à vérifier si sha (M + T + P ) = V. (sauf que sha peut prendre du temps constant pour le calcul de plus, cela ne porte pas atteinte à la complexité de la force brute sur P).

Cependant, étant donné le choix, vous devriez vraiment juste aller de l'avant et d'utiliser sha. Il n'y a pas de sens à ne pas l'utiliser, à moins d'un sérieux inconvénient à l'utiliser.

Une deuxième chose que vous devriez est probablement pas stocker le mot de passe de l'utilisateur dans votre base de données en texte brut. Ce que vous devez stocker est un hachage du mot de passe, puis de les utiliser. Dans votre exemple, le hachage serait: 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 quelque chose comme une injection SQL) serait toujours en mesure de forger des messages. Je ne vois aucune façon de contourner cela.

La réponse de Brian couvre les questions, mais je pense qu'il a besoin d'être expliqué un peu moins verbeux

Vous utilisez le mauvais algorithme de Crypto ici

MD5 est faux ici, SHA1 est erroné d'utiliser ici Sha2xx est erroné d'utiliser et Skein est erroné d'utiliser.

Ce que vous devez utiliser est quelque chose comme RSA .

Laissez-moi vous expliquer:

Votre hachage sécurisé envoie effectivement le mot de passe pour le monde de voir.

Vous mentionnez que votre hachage est « temps + charge utile + mot de passe », si un tiers obtient une copie de votre charge utile et connaît le temps. Il peut trouver le mot de passe (en utilisant une force brute ou attaque par dictionnaire). Ainsi, presque comme si vous envoyez le mot de passe en texte clair.

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

Aucun homme au milieu sera 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 forte la plupart du temps.

Cela dépend de la valeur du contenu des messages sont. La famille SHA est manifestement plus sécurisé que MD5 (où « plus sûr » signifie « plus difficile à falsifier »), mais si vos messages sont mises à jour twitter, vous ne se soucient probablement pas.

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

Mise à jour: Je dois ajouter aussi que les deux algorithmes sont essentiellement interchangeables digérer à bien des égards, alors combien plus de mal serait-il vraiment d'utiliser une plus sûre

Mise à jour 2: ceci est une réponse beaucoup plus approfondie: http: //www.schneier. com / essai-074.html

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

Comment est-ce commun? En 2007, un groupe des Pays-Bas ont annoncé qu'ils avaient prédit le vainqueur de l'élection présidentielle américaine de 2008 dans un fichier avec la valeur de hachage MD5 3D515DEAD7AA16560ABA3E9DF05CBC80 . Ils ont ensuite créé douze fichiers, tous identiques, sauf pour le nom et un nombre arbitraire d'espaces suivants, à cette valeur hachée du candidat. La valeur de hachage MD5 est sans valeur comme une somme de contrôle, parce que trop de fichiers différents donnent le même résultat.

Ceci est le même scénario que le vôtre, si je vous en train de lire. Il suffit de remplacer « le nom du candidat » avec « mot de passe secret ». Si vous voulez vraiment être sûr, vous devriez probablement utiliser une fonction de hachage différente.

si vous allez générer un hachage-mac ne pas inventer votre système. utiliser HMAC . il y a des problèmes avec faire HASH (clé secrète || message) et HASH (un message || clé secrète). si vous utilisez un mot de passe comme une clé que vous devez également utiliser une fonction de dérivation de clé. jetez un oeil à pbkdf2 .

Oui, il vaut la peine à vous soucier de hachage à utiliser dans ce cas. Regardons le modèle d'attaque en premier. Un attaquant pourrait ne pas seulement essayer de générer des valeurs md5 (M + T + P), mais peut aussi trouver le mot de passe P. En particulier, si l'attaquant peut recueillir tupels des valeurs M _i, T _i, et le (i , T _i, P M _{) puis il / elle pourrait essayer de trouver P. md5 correspondant Ce problème n » t été étudié autant 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ées contre les chiffrements par bloc: par exemple attaques différentielles. Et comme MD5 déjà très sensible aux attaques différentielles, je peux certainement imaginer qu'une telle attaque pourrait réussir ici.}

Par conséquent, je ne vous recommande d'utiliser une fonction de hachage MD5 plus forte que ici. Je recommande également que vous utilisez 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ée.

Il n'y a rien d'insécurité sur l'utilisation MD5 de cette manière. MD5 a été interrompu que dans la mesure où, il existe des algorithmes qui, étant donné un paquet de données A données supplémentaires B peut être généré pour créer une table de hachage désiré. Ce qui signifie, si quelqu'un connaît le hachage d'un mot de passe, ils pourraient produire une chaîne qui entraînera avec ce hachage. Bien que, ces chaînes générées sont généralement très longues, donc si vous limitez les mots de passe à 20 ou 30 caractères que vous êtes probablement encore sûr.

La principale raison d'utiliser SHA1 sur MD5 est que les fonctions MD5 sont éliminés progressivement. Par exemple, la bibliothèque .Net Silverlight ne comprend pas le fournisseur de cryptographie MD5.

MD5 fournir plus de collision SHA qui signifie que quelqu'un peut réellement obtenir même hachage de mot différent (mais il est rarement).

famille SHA est connue pour sa fiabilité, SHA1 est standard sur une utilisation quotidienne, alors que SHA256 / SHA512 était une norme pour les appareils gouvernementaux et bancaires.

Pour votre site personnel ou 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 (famille SHA2)

Vous pouvez consulter wikipedia article sur MD5 et SHA

Les deux MD5 amd SHA-1 ont des faiblesses cryptographiques. MD4 et SHA-0 sont également compromis.

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

Voir la powerpoint suivante de l'Université de Princeton, faites défiler jusqu'à la dernière page.

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

Je ne vais pas commenter le MD5 / SHA1 / etc. question, donc peut-être que vous allez examiner cette réponse sans objet, mais quelque chose qui me divertit est très légèrement chaque fois que l'utilisation de MD5 et al. des mots de passe dans les bases de données de hachage arrive.

Si quelqu'un farfouillé dans votre base de données, ils pourraient très bien vouloir regarder vos hashs, mais il est tout aussi probable qu'ils vont vouloir voler des informations personnelles ou d'autres données que vous trouverez autour dans d'autres les tables. Franchement, dans cette situation, vous avez plus gros poissons à frire.

Je ne dis pas ignorer la question, et comme je l'ai dit, cela n'a pas vraiment beaucoup incidence sur si oui ou non vous devez utiliser MD5, SHA1 ou quoi de hachage vos mots de passe, mais je ne suis chatouillé un peu rose tous les J'ai lu quelqu'un le temps d'obtenir un peu trop bouleversé les mots de passe en texte clair dans une base de données.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow