Question:
Est-ce une mauvaise pratique de préfixer mon hachage avec l'algorithme utilisé?
Mathias Lykkegaard Lorenzen
2018-11-08 19:25:07 UTC
view on stackexchange narkive permalink

Disons que j'ai une base de données avec un tas d'utilisateurs. Cette base de données utilisateur aurait généralement un mot de passe haché par utilisateur. Serait-ce une mauvaise pratique de préfixer ce hachage avec l'algorithme de hachage utilisé?

Par exemple, au lieu du hachage aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d , je stocke sha1_aaf4c61ddcc5e8a2dabede0f3b482 depuis la méthode pour faire le hachage est SHA1.

J'ai remarqué qu'Argon2 fait cela, et je pense en fait que c'est assez pratique, car cela facilite la migration partielle vers de nouveaux algorithmes de hachage pour les nouveaux utilisateurs au fil du temps.

Je n'utilise pas SHA1 dans mon code de production pour les mots de passe. SHA1 a été choisi au hasard. Cette question ne concerne pas l'utilisation de la méthode de hachage.

Les commentaires ne sont pas destinés à une discussion approfondie;cette conversation a été [déplacée vers le chat] (https://chat.stackexchange.com/rooms/85699/discussion-on-question-by-mathias-lykkegaard-lorenzen-is-it-bad-practice-to-pref).
Cinq réponses:
schroeder
2018-11-08 19:28:19 UTC
view on stackexchange narkive permalink

De nombreux systèmes de hachage de mots de passe différents le font. Le type de mécanisme de hachage utilisé ne doit pas être (et ne doit pas nécessairement être) un secret. Le principe de Kerckhoffs dit:

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.

Donc, si votre système est correctement sécurisé, peu importe si le mécanisme de hachage est exposé.

Pourquoi «ne devrait pas être»?Le principe de Kerckhoffs ne devrait pas être nécessaire, mais tant que cela ne vous amène pas à compromettre la sécurité des clés, cela ne peut certainement pas nuire non plus si l'algorithme de hachage est également secret.
@leftaroundabout c'est à propos de Kerckhoffs.Sur le plan opérationnel et politique, classer l'algorithme de hachage en tant que secret est un problème.Il tente d'assurer la sécurité par l'obscurité, et il introduit des coûts de contrôle qui l'emportent sur les avantages.Sans parler du cas d'utilisation pratique fourni par Toby Speight.Il ne s'agit pas de préfixer le type alo, il s'agit de la classification des données sur le type algo.
Il n'est pas nécessaire de le classer en tant que secret pour qu'il soit secret.Cela peut être secret par ailleurs, pour des raisons de performances.
Différence entre en faire un secret et, accessoirement, ne pas le divulguer.Dans ce cas, la question porte sur la classification de ces données, pas sur la non-divulgation (bien que le contexte soit sur la divulgation).
J'avais l'impression que l'ajout de "sécurité par l'obscurité" est toujours une bonne chose.Les systèmes * devraient * être sécurisés, même si vous connaissez tous les détails du système, mais l'ajout d'obscurité ajoute de la sécurité (pour ralentir les attaquants, pour cacher les systèmes lorsque des bogues de 0 jour sont trouvés, etc.).C'est si juste?
@NathanMerrill Je dirais que cela devrait être pris au cas par cas.Dans ce cas, je pense que l'avantage d'avoir l'algorithme stocké avec le hachage l'emporte largement sur le très léger avantage de sécurité que vous obtiendriez en l'obscurcissant.
Je devrai être d'accord avec @leftaroundabout.Cette interprétation de Kerckhoff est à mon avis tout aussi imparfaite que l'interprétation courante du rasoir d'Occam qui dit que "la solution la plus simple est toujours juste".Faire d'un détail d'implémentation un secret (ou du moins un peu obscur) n'est pas mauvais tant que vous ne vous y fiez pas comme mesure de sécurité.Cela rend la vie d'un attaquant inexpérimenté un peu plus difficile, cependant.De nombreuses entreprises ont leur "sauce secrète", a.k.a., les secrets commerciaux protégés par des moyens légaux (qui fonctionneront même si le secret est connu) mais _toujours_ ils gardent leurs secrets _secret_.
@Damon bien, ce que je voulais dire, c'est qu'il n'est pas bon de regrouper les détails d'implémentation en texte clair avec un chiffrement juste pour «adhérer au principe de Kerckhoffs».Cela ne vous achète rien, à moins que cela n'ait des avantages indépendants (comme faciliter la migration vers un autre hachage, mais pour cela, ajouter le nom du hachage en ASCII n'est pas la seule option et sans doute assez hacky).La publication délibérée des détails de l'implémentation n'est un _avantage_ que si elle est effectuée de manière à vous donner un examen par les pairs (bibliothèque open source, etc.).Si rien de tout cela ne s'applique, restez simple et omettez le nom de l'algorithme.
Le principe d'@NathanMerrill Kerkhoff est utilisé pour permettre le durcissement des systèmes.Si tout sauf la clé est ouvert, il peut être examiné de manière approfondie.Si des parties du système ne sont pas ouvertes, quiconque tente de vérifier sa sécurité doit procéder à une rétro-ingénierie de ces pièces avant de pouvoir les évaluer correctement.
@leftaroundabout: Exactement, c'est ce que je dis.Publier un secret pour "parce que Kerckhoff!"est une mauvaise interprétation de ce principe (à mon avis).
@Deduplicator c'est vrai: vous voulez que ce soit obscur pour les attaquants, mais pas obscur pour les évaluateurs.Il y a certainement des scénarios où cela n'est pas possible.
Anders
2018-11-08 19:41:49 UTC
view on stackexchange narkive permalink

Je suis d'accord avec schroeder que c'est OK à faire. Même sans préfixe, un attaquant peut probablement découvrir quel algorithme vous utilisez. Et de toute façon, c'est la force de l'algorithme de hachage qui protège les mots de passe, pas le secret de l'algorithme.

Notez que de nombreux algorithmes et bibliothèques de hachage le font déjà pour vous. Ils intègrent toutes les informations pertinentes - algorithme, facteurs de coût, sel, hachage réel - dans une chaîne sérialisée. Voir par exemple le Modular Crypt Format ou la fonction PHP password_hash. Alors n'allez pas inventer votre propre plan. Si vous utilisez une bibliothèque de hachage de descente, vous en avez déjà une.

N'utilisez pas SHA1 pour hacher les mots de passe, cependant. Ce n'est pas correct.

Ouais j'ai utilisé SHA1 parce que le hash de "bonjour" était trop long pour un exemple en SHA512.
@MathiasLykkegaardLorenzen N'utilisez pas SHA512 non plus, à moins que ce ne soit juste un composant dans un schéma plus grand avec plus d'itérations.Mais bien sûr pour un exemple, tout est permis!:-)
@MathiasLykkegaardLorenzen Et n'utilisez pas seulement plusieurs itérations!Utilisez une construction éprouvée comme PBKDF2, qui utilise HMAC (pas seulement des itérations de hachage brutes).
Le SHA512 est-il considéré comme non sécurisé?Je ne savais pas cela à ce moment.Pouvez-vous citer un article expliquant pourquoi?
Ce n'est pas non plus sûr pour ce pour quoi il a été conçu (c'est-à-dire le hachage des données), mais il a été conçu pour être * rapide *.Vous voulez que votre fonction de hachage de mot de passe soit lente pour éviter les tentatives de force brute.
Mais même si c'est rapide, est-il important que le nombre de tentatives qui seraient nécessaires (étant donné qu'un sel et du poivre sont ajoutés) soit toujours incroyablement élevé?
Oui, cela compte toujours.Les fonctions de hachage ne sont pas destinées au stockage des mots de passe en raison de leur vitesse.Avec une seule instance p3.16xlarge sur Amazon, vous pouvez effectuer 17,28 milliards d'estimations par seconde sur SHA512.Cela signifie que vous pouvez déchiffrer n'importe quel mot de passe de 8 caractères composé de lettres et de chiffres en seulement 151,17 secondes.Les fonctions de dérivation de clé sont conçues pour stocker les mots de passe car ils sont lents.Avec bcrypt sur workfactor 12, vous ne pouvez faire que 424200 estimations par seconde.Cela prendrait 34,8 jours par mot de passe.De plus, bcrypt et argon2 ont intégré des sels, vous n'avez donc pas à vous soucier de saler les mots de passe.
Toby Speight
2018-11-08 21:59:44 UTC
view on stackexchange narkive permalink

Non, ce n'est pas une mauvaise pratique, et sans doute, vous devriez conserver ces informations.

Comme vous le constatez, cela vous permet de changer d'algorithme pour les nouveaux mots de passe quand vous le souhaitez, sans invalider les mots de passe existants de tous les utilisateurs (cela a tendance à vous rendre impopulaire, pour une raison quelconque).

Il y a un argument selon lequel cela permet à un attaquant de rechercher les mots de passe les plus anciens et les plus faibles pour attaquer en premier, mais vous n'ont pas du tout réduit leur sécurité (en supposant le principe de Kerckhoff, que l'algorithme lui-même ne doit pas avoir besoin d'être un secret).

Si l'on peut stocker une combinaison d'algorithmes et de sels, il n'est pas nécessaire de conserver des mots de passe plus faibles une fois que des algorithmes plus puissants sont disponibles.Si l'entrée actuelle dit que mettre le mot de passe via lowAlgorithm avec salt1 donne X, calculez simplement Y en mettant X via un strongAlgorithm avec salt2 puis changez l'entrée pour dire que mettre le mot de passe via lowAlgorithm avec salt1, puis en mettant le résultat de *que * grâce à un algorithme plus fort avec salt2, donnera Y. Pas besoin d'attendre que l'utilisateur se connecte.
leo v
2018-11-09 01:27:51 UTC
view on stackexchange narkive permalink

C'est une bonne pratique de stocker l'algorithme de hachage, mais des fonctions de hachage de mot de passe appropriées telles que Argon2 et PBKDF2 s'en chargent déjà. Il est cependant une mauvaise pratique d'utiliser SHA1 ou SHA256 seul pour le hachage de mot de passe car il s'agit d'une quantité fixe (et relativement petite) de travail à craquer à l'aide d'attaques par dictionnaire et de force brute. Ces mots de passe doivent être migrés vers une fonction de hachage sécurisée en ressassant le mot de passe lors de leur prochaine connexion. Voir https://crypto.stackexchange.com/a/45405 pour plus de détails.

Nicolas Marshall
2018-11-10 00:11:22 UTC
view on stackexchange narkive permalink

Ce n'est pas une mauvaise pratique, c'est en fait une chose courante à faire. En fait, si vous ouvrez le fichier / etc / shadow sur une machine Linux, vous verrez votre mot de passe haché précédé de $ x $ salt $ où x est un nombre indiquant quel algorithme de hachage a été utilisé.

Maintenant, quelques points à considérer:

  • n'utilisez pas SHA1 directement comme algorithme de hachage. Utilisez à la place bcrypt, scrypt ou argon2 (que vous avez mentionné, mais cela ne peut pas être répété trop). Ceux-ci utilisent un algorithme de hachage simple comme SHA1 comme base, mais ils l'exécutent d'une manière spéciale qui le rend résistant aux attaques.
  • pour des raisons pratiques, puisque vous utilisez une base de données et non un fichier, vous souhaiterez peut-être stocker la méthode de hachage et le sel dans des lignes séparées. Cependant, vous pouvez également choisir de stocker la chaîne commençant par $ x $ salt $ dans votre base de données et d'analyser le sel et la méthode de hachage à partir de cette chaîne au moment où vous vérifiez le mot de passe. C'est probablement assez rapide pour que cela ne fasse aucune différence significative. Et dans les deux cas, la sécurité de votre système sera la même.
L'OP dit dans ses commentaires que SHA-1 n'a été utilisé qu'à titre d'exemple et n'est pas utilisé en production
Il faut utiliser plus que "exécuter ça plusieurs fois", il faut avoir une utilisation du processeur ou ~ 100ms et un sel aléatoire.
@schroeder Je n'étais pas si sûr en lisant la question.
@zaph est tout à fait d'accord, mais je ne voulais pas entrer dans les détails.J'ai modifié ma réponse pour la rendre moins ambiguë


ⓘ
Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 4.0 sous laquelle il est distribué.
Loading...