Utiliser un hachage de données comme un sel

Question

Je me demandais - y at-il des inconvénients à utiliser le hachage de quelque chose comme un sel de lui-même?

E.g. hashAlgorithm (data + hashAlgorithm (data))

Cela empêche l'utilisation des tables de recherche et ne nécessite pas le stockage d'un sel dans la base de données. Si l'attaquant n'a pas accès au code source, il ne pourrait pas obtenir l'algorithme, ce qui rendrait le forçage brutal plus difficile.

Pensées? (J'ai un pressentiment que cela est mauvais - mais je voulais vérifier si elle est vraiment, et si oui, pourquoi.)

Answer 1

Si l'attaquant n'a pas accès au code source

Ceci est appelé "security through obscurity", ce qui est toujours considéré comme mauvais. Une méthode intrinsèquement sûre est toujours meilleure, même si la seule différence réside dans le fait que vous ne vous sentez pas sauvé "parce qu'ils ne savent pas comment". Quelqu'un peut et trouvera toujours l'algorithme - par le biais d'une analyse minutieuse, d'essais et d'erreurs, ou parce qu'il a trouvé la source en SSH-ing sur votre service d'hébergement partagé, ou sur une centaine d'autres méthodes.

Answer 2

Il est toujours préférable d'utiliser de vraies données aléatoires en tant que sel. Imaginez une implémentation où le nom d'utilisateur est pris comme valeur de sel. Cela conduirait à une sécurité réduite pour les noms communs comme "root" ou "admin".

Si vous ne voulez pas créer et gérer une valeur de sel pour chaque hachage, vous pouvez utiliser une application large de sel. Dans la plupart des cas, cela serait absolument suffisant et beaucoup d'autres choses seraient plus vulnérables que les hachages.

Answer 3

L'utilisation d'un hachage des données en tant que sel pour les données est et non sécurisé.

Le but du sel est de produire des résultats imprévisibles à partir d'entrées qui sont par ailleurs les mêmes. Par exemple, même si de nombreux utilisateurs sélectionnent la même entrée (comme un mot de passe, par exemple), après avoir appliqué un bon salt, vous (ou un attaquant) ne serez pas en mesure de le dire. Lorsque le sel est une fonction des données, un attaquant peut pré-calculer une table de recherche, car le sel pour chaque mot de passe est prévisible. Les meilleurs sels sont choisis parmi un générateur cryptographique pseudo-aléatoire initialisé avec une graine aléatoire. Si vous ne pouvez vraiment pas stocker un sel supplémentaire, pensez à utiliser quelque chose qui varie par utilisateur (comme un nom d'utilisateur), avec quelque chose d'spécifique à l'application (comme un nom de domaine). Ce n'est pas aussi bon qu'un sel aléatoire, mais il n'est pas fatalement défectueux. Rappelez-vous, un sel n'a pas besoin d'être secret, mais il ne peut pas être une fonction des données étant salées.

Answer 4

Cela offre aucune amélioration par rapport au simple hachage. Utilisez un sel généré de manière aléatoire.

Le point de salage consiste à faire en sorte que deux hachages de valeurs distinctes chronologiquement diffèrent et, ce faisant, interrompent les tables de consultation pré-calculées.

Considérez:

data = "test"
hachage = hachage ("test" + hachage ("test"))

Hash sera constante à chaque fois que les données = "test" . Ainsi, si l'attaquant a l'algorithme (et que l'attaquant a toujours l'algorithme), il peut pré-calculer les valeurs de hachage pour un dictionnaire d'entrées de données.

Answer 5

Ceci n'est pas du sel - vous venez de modifier la fonction de hachage. Au lieu d'utiliser la table de recherche pour le hashAlgorithm d'origine, l'attaquant peut simplement obtenir la table pour votre table modifiée; Cela n'empêche pas l'utilisation des tables de recherche.