Pourquoi le hachage MD5 commence-t-il à partir de 1 $ et SHA-512 à partir de 6 $? N'est-ce pas une faiblesse en soi?
J'ai déplacé cette question de stackoverflow à cet endroit. Je sais que c'est peut-être une question d '"opinion" mais je ne cherche pas une opinion privée mais une source de la décision finale de le garder ainsi.
On m'a appris que personne n'essaie d'ouvrir une porte quand on ne sait même pas que la porte existe. La meilleure défense serait alors de cacher une porte. On pouvait le voir facilement dans les vieux films de guerre - personne ne garderait une cachette à la lumière. Il a toujours été couvert de quelque chose suggérant qu '"il n'y a rien d'intéressant là-bas".
Je suppose qu'en cryptographie, cela fonctionnerait de la même manière. Pourquoi le hachage généré par MD5 commencerait-il à partir de $ 1 $, et dira-t-il en premier lieu ce qu'est un hachage, puis de quel type de hachage il s'agit (MD5)?
Maintenant, je vois que sha512 fait exactement la même chose. N'est-ce pas une faiblesse en soi? Y a-t-il une raison particulière pour que nous le fassions de cette façon?
La question principale est la suivante: devrais-je brouiller mon hachage avant de le stocker pour le cacher à un ennemi potentiel? S'il n'y a pas besoin de cela, alors pourquoi?
Pour éviter les réponses qui suggèrent que l'obscurité n'est pas la sécurité, je proposerais cette image. C'est la Seconde Guerre mondiale. Vous venez de recevoir un indice que SS arrive chez vous en soupçonnant que vous cachez des partisans, et c'est vrai. Ils n'ont pas le temps de s'échapper. Vous avez deux choix où vous pouvez les cacher - dans le meilleur coffre-fort au monde, ou dans le trou caché sous le sol, si bien caché que même vos parents ne se doutaient pas qu'il est là. Quelle est votre proposition? Pourriez-vous vous convaincre que le meilleur coffre-fort est le meilleur choix?
Si je sais qu'il y a un trésor caché sur une île, je voudrais savoir de quelle île il s'agit ou je ne commencerai pas à chercher.
Je ne suis toujours pas convaincu. Jusqu'à présent, Chris Jester-Young m'a donné matière à réflexion en suggérant qu'il peut y avoir plus d'algorithmes générant le même hachage à partir de données différentes.
Tout d'abord, il y a principe de Kerckhoffs qui est toujours souhaitable:
Un cryptosystème doit être sécurisé même si tout ce qui concerne le système, à l'exception de la clé, est de notoriété publique.
où dans ce cas le mot de passe est la clé. Ce n'est donc pas un objectif de garder le cryptosystème secret.
Deuxièmement, vous vous trompez au sujet de ceux qui sont des hachages md5 ou sha512; les valeurs stockées dans votre /etc/shadow sont md5crypt ou sha512crypt, ce qui implique une procédure de renforcement (plusieurs tours d'un hachage md5 ou sha512).
Maintenant, si vos quatre choix sont MD5crypt, sha256crypt, sha512crypt et bcrypt (les choix les plus populaires dans les systèmes Linux), voici quatre hachages générés avec $saltsalt$ (ou équivalent) en tant que sel et hachage du mot de passe not my real password:
>>> import crypt
>>> crypt.crypt('not my real password','$1$saltsalt')
'$1$saltsalt$4iXfpnrgHRXkrDbPymCE4/'
>>> crypt.crypt('not my real password','$5$saltsalt')
'$5$saltsalt$E0bMpsLR71z8LIvd6p2tD4LZ984JxyD7B9lPLhq4vY7'
>>> crypt.crypt('not my real password','$6$saltsalt')
'$6$saltsalt$KnqiStSM0GULvZdkTBbiPUhoHemQ7Q06YnvuJ0PWWZbjzx3m0RCc/hCfq54Ro3fOwaJdEAliX9igT9DD2oN1u/'
>>> import bcrypt
>>> bcrypt.hashpw('not my real password', "$2a$12$saltsaltsaltsaltsalt..")
'$2a$12$saltsaltsaltsaltsalt..FW/kWpMA84AQoIE.Qg1Tk5.FKGpxBNC'
Même sans l'annotation, il est assez simple de déterminer le schéma qu'ils utilisent chacun (md5crypt, sha256crypt, sha512crypt et bcrypt mesurent respectivement 34,55,98 et 60 caractères (en encodage base64 avec annotation et sel). Donc, sauf si vous suggérer de tronquer le hachage ou de modifier les propriétés de hachage, l'annotation pour la cohérence ne perd aucune sécurité. Elle vous donne également une méthode pour mettre à jour avec élégance les mots de passe des utilisateurs. Si vous décidez que md5crypt n'est plus sécurisé, vous pouvez basculer les hachages des utilisateurs sur bcrypt à la prochaine connexion (puis après un certain temps, désactivez tous les comptes restants sur md5crypt). Ou si votre algorithme comme bcrypt (quand il était de 2 $) doit être mis à jour, en raison d'un défaut de conception = vous pouvez facilement identifier les schémas défectueux lorsque le schéma fixe est passé à $ 2a $.
Pire encore, vous pourriez essayer de dire, je vais modifier sha512 avec de nouvelles constantes et touches rondes. Cela le rendrait très dur à casser - non? Non, il est juste très difficile pour vous de savoir que vous n'avez pas introduit accidentellement une vulnérabilité majeure. S'ils peuvent accéder à votre/etc/shadow, ils peuvent probablement également accéder à la bibliothèque utilisée pour vous connecter et avec le temps, pourraient inverser l'ingénierie de votre schéma de hachage et ce sera BEAUCOUP PLUS simple que de casser un mot de passe fort.
Encore une fois, le temps prévu pour forcer brutalement une phrase secrète très forte stockée dans le hachage sha256 est O (2 ^ 256), par exemple, un milliard d'ordinateurs faisant un milliard de sha256crypts par nanoseconde (chacun impliquant environ 5000 tours de sha256), il faudrait 300000000000000000000000 (3 x 10 ^ 23) fois l'âge de l'univers pour le briser. Et avec sha512crypt, si chacun des ~ 10 ^ 80 atomes de l'univers observable faisait chacun un milliard de sha512crypt à chaque nanoseconde, cela prendrait encore 10 ^ 38 fois l'âge de l'univers. (Cela suppose que vous avez une phrase secrète d'entropie 256 bits et 512 bits ou plus).
L'obscurcissement du hachage utilisé empêche le système d'authentifier le mot de passe d'un utilisateur légitime.
Lorsque l'authentification par mot de passe via le hachage dans Unix a été inventée pour la première fois, la fonction de hachage du mot de passe a été codée en dur pour utiliser DES (maintenant mal obsolète). Si le hachage du mot de passe est dérivé par une autre fonction, il y a doit être un identifiant pour permettre au système de reconnaître l'algorithme utilisé pour générer le hachage.
En effet, le hachage de mot de passe est une fonction à sens unique. J'ai entendu dire que s'attendre à exécuter une telle fonction à sens unique en sens inverse, c'est comme s'attendre à diriger une fabrique de saucisses à l'envers et à faire sortir des porcs de l'autre côté. Ainsi, lorsque vous allez authentifier une personne qui se connecte au système, vous ne pouvez exécuter que la fonction de hachage et comparer les résultats avec ce qui est stocké dans/etc/shadow.
Ces identifiants doivent donc rester en clair, sinon la mauvaise fonction de hachage sera utilisée, les hachages ne correspondront pas et personne ne pourra entrer dans le système.
Tenter de masquer l'implémentation du hachage ne fait que déplacer le problème, de
- Je peux voir par protocole que la fonction de hachage est X ()
à
- En regardant le code **, je peux dire que la fonction de hachage est X ()
** (ou autre canal d'information latéral)
Si votre attaquant a un moyen de sonder le système, il sera presque certainement en mesure de comprendre l'algorithme que vous utilisez. Le plus simple est de simplement regarder le code (code source ou code machine), les méthodes plus compliquées impliquent l'utilisation de mesures de synchronisation pour différencier la fonction utilisée. Pour utiliser votre analogie "cacher les gens" - tout ce qu'il faut, c'est que je monte avec un équipement de sondage et je peux dire avant même d'entrer dans le bâtiment qu'il y a des salles souterraines.
Je sais que vous ne vouliez pas l'entendre, mais la réalité est que "la sécurité par l'obscurité" échoue inévitablement en raison d'une incapacité à obscurcir suffisamment, de toutes les approches possibles, les deux approches connues aujourd'hui, ou une approche future.