37 votes

Plusieurs itérations de hachage : ajouter le sel à chaque fois ?

J'ai longtemps utilisé du md5/sha1 non salé, mais comme cette méthode n'est pas vraiment sûre (et le devient de moins en moins avec le temps), j'ai décidé de passer à du sha512 salé. De plus, je veux ralentir la génération du hachage en utilisant de nombreuses itérations (par exemple 100).

Ma question est de savoir si je dois ajouter le sel à chaque itération ou seulement une fois au début. Voici les deux codes possibles :

Ajouter à chaque fois :

// some nice big salt
$salt = hash($algorithm, $salt);

// apply $algorithm $runs times for slowdown
while ($runs--) {
    $string = hash($algorithm, $string . $salt, $raw);
}

return $string;

Ajouter une fois :

// add some nice big salt
$string .= hash($algorithm, $salt);

// apply $algorithm $runs times for slowdown
while ($runs--) {
    $string = hash($algorithm, $string, $raw);
}

return $string;

Je voulais d'abord utiliser la deuxième version (append once) mais j'ai ensuite trouvé des scripts apposant le sel à chaque fois.

Je me demande donc si le fait de l'ajouter à chaque fois renforce le hachage. Par exemple, serait-il possible qu'un attaquant trouve un moyen astucieux de créer une fonction 100timesSha512 qui soit bien plus rapide que la simple exécution de sha512 100 fois ?

51voto

ircmaxell Points 74865

En bref : Oui. Allez-y avec le premier exemple... La fonction de hachage peut perdre de l'entropie si elle est réinjectée dans elle-même sans ajouter les données d'origine (je n'arrive pas à trouver une référence maintenant, je vais continuer à chercher).

Et pour information, je suis en faveur du hachage multiple.

Un hachage qui prend 500 ms à générer n'est pas trop lent pour votre serveur (sachant que la génération de hachages n'est généralement pas effectuée par la grande majorité des requêtes). Cependant, un hachage aussi long augmentera considérablement le temps nécessaire à la génération d'une table arc-en-ciel...

Oui, cela expose une vulnérabilité DOS, mais cela empêche également les attaques par force brute (ou du moins les rend excessivement lentes). Il y a absolument un compromis à faire, mais pour certains, les avantages dépassent les risques...

Une référence (plutôt un aperçu) de l'ensemble du processus : Renforcement essentiel

Quant aux collisions dégénérantes, la seule source que j'ai pu trouver jusqu'à présent est cette discussion ...

Et d'autres discussions sur le sujet :

  1. Proposition de l'EPER
  2. Blog de SecurityFocus sur le hachage
  3. Un document sur les algorithmes de hachage des mots de passe d'Oracle.

Et quelques liens supplémentaires :

  1. PBKDF2 sur WikiPedia
  2. PBKDF2 Standard
  3. Un fil de discussion sur les courriels qui s'applique
  4. Le simple hachage est loin d'être suffisant Blog Post

Il y a des tonnes de résultats. Si vous en voulez plus, Google hash stretching ... Il y a des tonnes de bonnes informations là-bas...

6voto

NullUserException Points 42268

En plus d'effectuer un nouveau hachage plusieurs fois, j'utiliserais un sel différent pour chaque mot de passe/utilisateur. Bien que je pense que 5000 itérations soit un peu trop, essayez un nombre inférieur. Il y a un compromis à faire ici ; vous devrez l'ajuster en fonction de vos besoins et de votre matériel.

Avec des sels différents pour chaque mot de passe, un attaquant serait obligé de forcer chaque mot de passe individuellement au lieu de construire une table arc-en-ciel, ce qui augmente considérablement la charge de travail.

Comme toujours, voici une lecture recommandée pour cela : Un simple hachage est loin d'être suffisant

EDIT : Le hachage itératif est une tactique parfaitement valable . Il y a des compromis à faire, mais tout le monde en fait. Si vous vous inquiétez du temps de calcul, pourquoi ne pas simplement stocker le mot de passe en clair ?

3voto

Marcin Points 1409

S'il vous plaît, s'il vous plaît, ne lancez pas votre propre crypto. C'est à cela que servent les bibliothèques comme OpenSSL. Voici quelques bons exemples de la façon dont vous pouvez l'utiliser pour faire des hachages salés.

Les hachages salés dans OpenSSL

0voto

blaze Points 2930

La raison du hachage itératif est de rendre le processus aussi lent que possible. Vous pouvez donc faire encore mieux : utiliser des sels différents pour chaque itération. Cela peut être fait en chiffrant vos données originales encore et encore à chaque itération avec une clé fixe et en faisant un XOR avec la valeur du sel.

0voto

xPheRe Points 1167

Je préfère opter pour un double sha1 avec deux sels différents et prévenir les DoS en retardant la réponse de manière incrémentielle (avec un simple usleep) pour chaque vérification de mot de passe invalide.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X