Comment le sel de mot de passe aide-t-il contre une attaque de type "rainbow table" ?

Question

J'ai du mal à comprendre l'utilité d'un sel pour un mot de passe. J'ai cru comprendre que sa principale utilité est d'entraver une attaque de type "rainbow table". Cependant, les méthodes que j'ai vues pour mettre en œuvre ce principe ne semblent pas vraiment rendre le problème plus difficile.

J'ai vu de nombreux tutoriels suggérant d'utiliser le sel comme suit :

$hash =  md5($salt.$password)

Le raisonnement est que le hachage ne correspond plus au mot de passe original, mais à une combinaison du mot de passe et du sel. Mais disons que $salt=foo y $password=bar y $hash=3858f62230ac3c915f300c664312c63f . Maintenant, quelqu'un avec une table arc-en-ciel pourrait inverser le hachage et obtenir l'entrée "foobar". Il pourrait alors essayer toutes les combinaisons de mots de passe (f, fo, foo, ... oobar, obar, bar, ar, ar). Cela pourrait prendre quelques millisecondes de plus pour obtenir le mot de passe, mais pas beaucoup plus.

L'autre utilisation que j'ai vue est sur mon système linux. Dans le fichier /etc/shadow, les mots de passe hachés sont en fait stockés. avec le sel. Par exemple, un sel de "foo" et un mot de passe de "bar" donneraient le résultat suivant : $1$foo$te5SBM.7C25fFDu6bIRbX1 . Si un hacker parvenait à mettre la main sur ce fichier, je ne vois pas à quoi sert le sel, puisque le hachage inverse de te5SBM.7C25fFDu6bIRbX est connu pour contenir "foo".

Merci pour toute lumière que quelqu'un peut apporter sur ce sujet.

EDITAR : Merci pour votre aide. Pour résumer ce que je comprends, le sel rend le mot de passe haché plus complexe, ce qui le rend beaucoup moins susceptible d'exister dans une table arc-en-ciel précalculée. Ce que j'ai mal compris auparavant, c'est que je supposais qu'une table arc-en-ciel existait pour TOUS les hashs.

Answer 1

Un sel public no rendre les attaques par dictionnaire plus difficiles lorsqu'il s'agit de craquer un seul mot de passe. Comme vous l'avez souligné, l'attaquant a accès à la fois au mot de passe crypté et au sel, de sorte que lors de l'attaque par dictionnaire, il peut simplement utiliser le sel connu pour tenter de craquer le mot de passe.

Un sel public a deux effets : il rend plus long le craquage d'une grande liste de mots de passe et rend infaisable l'utilisation d'une table arc-en-ciel.

Pour comprendre la première, imaginez un fichier de mots de passe unique qui contient des centaines de noms d'utilisateur et de mots de passe. Sans sel, je pourrais calculer "md5(tentative[0])", puis parcourir le fichier pour voir si ce hachage apparaît quelque part. Si des sels sont présents, je dois alors calculer "md5(salt[a] . attempt[0])", comparer avec l'entrée A, puis "md5(salt[b] . attempt[0])", comparer avec l'entrée B, etc. Maintenant, j'ai n fois plus de travail à faire, où n est le nombre de noms d'utilisateur et de mots de passe contenus dans le fichier.

Pour comprendre la seconde, vous devez comprendre ce qu'est une table arc-en-ciel. Une rainbow table est une grande liste de hachages pré-calculés pour les mots de passe les plus utilisés. Imaginez à nouveau le fichier de mots de passe sans sels. Tout ce que j'ai à faire est de parcourir chaque ligne du fichier, d'extraire le mot de passe haché et de le rechercher dans la rainbow table. Je n'ai jamais eu à calculer un seul hachage. Si la consultation est considérablement plus rapide que la fonction de hachage (ce qui est probablement le cas), cela accélérera considérablement le craquage du fichier.

Mais si le fichier de mots de passe est salé, alors la table arc-en-ciel devrait contenir "salt . password" pré-haché. Si le sel est suffisamment aléatoire, c'est très peu probable. Je vais probablement avoir des choses comme "hello" et "foobar" et "qwerty" dans ma liste de mots de passe pré-cachés couramment utilisés (la table arc-en-ciel), mais je ne vais pas avoir des choses comme "jX95psDZhello" ou "LPgB0sdgxfoobar" ou "dZVUABJtqwerty" pré-calculées. Cela rendrait la table arc-en-ciel excessivement grande.

Ainsi, le sel réduit l'attaquant à un calcul par rangée par tentative, ce qui, associé à un mot de passe suffisamment long et aléatoire, est (généralement) inviolable.

Answer 2

Les autres réponses ne semblent pas répondre à vos incompréhensions du sujet, alors je vais y aller :

Deux utilisations différentes du sel

J'ai vu de nombreux tutoriels suggérant d'utiliser le sel comme suit :

$hash = md5($salt.$password)

[...]

L'autre utilisation que j'ai vue est sur mon système linux. Dans le fichier /etc/shadow, les mots de passe hachés sont en fait stockés avec le sel.

Vous siempre Vous devez stocker le sel avec le mot de passe, car pour valider ce que l'utilisateur a saisi par rapport à votre base de données de mots de passe, vous devez combiner la saisie avec le sel, la hacher et la comparer au hachage stocké.

Sécurité du hachage

Maintenant, quelqu'un avec une table arc-en-ciel pourrait inverser le hachage et obtenir l'entrée "foobar".

[...]

puisque le hachage inverse de te5SBM.7C25fFDu6bIRbX est connu pour contenir "foo".

Il n'est pas possible d'inverser le hachage en tant que tel (en théorie, du moins). Le hachage de "foo" et le hachage de "saltfoo" ont rien en commun. La modification d'un seul bit à l'entrée d'une fonction de hachage cryptographique devrait changer complètement la sortie.

Cela signifie que vous ne pouvez pas construire une table arc-en-ciel avec les mots de passe courants, puis la "mettre à jour" plus tard avec du sel. Vous devez prendre en compte le sel dès le début.

C'est la raison pour laquelle vous avez besoin d'une table arc-en-ciel en premier lieu. Comme il est impossible d'obtenir le mot de passe à partir du hachage, vous calculez au préalable tous les hachages des mots de passe les plus susceptibles d'être utilisés, puis vous comparez vos hachages à leurs hachages.

Qualité du sel

Mais dites $salt=foo

"foo" serait un extrêmement mauvais choix de sel. Normalement, vous devriez utiliser une valeur aléatoire, codée en ASCII.

De plus, chaque mot de passe possède son propre sel, différent (espérons-le) de tous les autres sels du système. Cela signifie que l'attaquant doit attaquer chaque mot de passe individuellement au lieu d'avoir l'espoir que un des hachages correspond à l'une des valeurs de sa base de données.

L'attaque

Si un hacker parvenait à mettre la main sur ce fichier, je ne vois pas à quoi sert le sel,

Une attaque de type rainbow table siempre besoins /etc/passwd (ou n'importe quelle base de données de mots de passe utilisée), ou alors comment comparer les hachages dans la table arc-en-ciel aux hachages des mots de passe réels ?

Quant à l'objectif : disons que l'attaquant veut construire une table arc-en-ciel pour 100 000 mots anglais couramment utilisés et des mots de passe typiques (pensez à "secret"). Sans sel, il devrait précalculer 100 000 hachages. Même avec le sel traditionnel UNIX de 2 caractères (chacun est un des 64 choix possibles : [a–zA–Z0–9./] ), elle aurait dû calculer et stocker 4 096 000 000 hachages... une sacrée amélioration.

Answer 3

L'idée du sel est de rendre le mot de passe beaucoup plus difficile à deviner par force brute qu'un mot de passe normal basé sur des caractères. Les tables arc-en-ciel sont souvent construites en tenant compte d'un jeu de caractères spéciaux et n'incluent pas toujours les éléments suivants todo combinaisons possibles (bien qu'elles le puissent).

Une bonne valeur de sel serait donc un nombre entier aléatoire de 128 bits ou plus. C'est ce qui fait échouer les attaques de type "rainbow-table". En utilisant une valeur de sel différente pour chaque mot de passe stocké, vous vous assurez également qu'une table arc-en-ciel construite pour une valeur de sel particulière (comme cela pourrait être le cas si vous êtes un système populaire avec une seule valeur de sel) ne vous donne pas accès à tous les mots de passe à la fois.

Answer 4

Encore une excellente question, avec de nombreuses réponses très réfléchies - +1 à SO !

Un petit point que je n'ai pas vu mentionné explicitement est qu'en ajoutant un sel aléatoire à chaque mot de passe, vous garantissez virtuellement que deux mots de passe ne seront pas utilisés. Les utilisateurs qui ont choisi le même mot de passe produiront des hachages différents.

Pourquoi est-ce important ?

Imaginez la base de données des mots de passe d'une grande société de logiciels du nord-ouest des États-Unis. Supposons qu'elle contienne 30 000 entrées, dont 500 contiennent le mot de passe écran bleu . Supposons en outre qu'un pirate parvienne à obtenir ce mot de passe, par exemple en le lisant dans un courriel adressé par l'utilisateur au service informatique. Si les mots de passe ne sont pas hachés, le pirate peut trouver la valeur hachée dans la base de données, puis il lui suffit de procéder à une comparaison de motifs pour avoir accès aux 499 autres comptes.

En salant les mots de passe, on s'assure que chacun des 500 comptes a un (sel+mot de passe) unique, ce qui génère un hachage différent pour chacun d'eux et réduit ainsi la violation à un seul compte. Et espérons, contre toute attente, que tout utilisateur assez naïf pour écrire un mot de passe en clair dans un message électronique n'ait pas accès à l'API non documentée du prochain système d'exploitation.

Answer 5

Je cherchais une bonne méthode pour appliquer des sels et j'ai trouvé cet excellent article avec un exemple de code :

http://crackstation.net/hashing-security.htm

L'auteur recommande d'utiliser des sels aléatoires par utilisateur, afin que l'accès à un sel ne rende pas la liste entière de hachages aussi facile à craquer.

Pour enregistrer un mot de passe :

• Générer un sel aléatoire long en utilisant un CSPRNG.
• Faites précéder le mot de passe du sel et hachurez-le avec une fonction de hachage fonction de hachage cryptographique standard telle que SHA256.
• Enregistrez le sel et le hachage dans l'enregistrement de la base de données de l'utilisateur.

Pour valider un mot de passe :

• Récupérer le sel et le hachage de l'utilisateur dans la base de données.
• Préparez le sel au mot de passe donné et hachurez-le en utilisant la même fonction de hachage.
• Comparez le hachage du mot de passe donné avec le hachage de la base de données. S'ils correspondent, le mot de passe est correct. Sinon, le mot de passe est incorrect.