Comment le sel de mot de passe peut-il aider contre une attaque de table arc-en-ciel?

J'ai du mal à comprendre le but d'un sel sur un mot de passe. Je crois comprendre que l'utilisation principale est d'entraver une attaque de table arc-en-ciel. Cependant, les méthodes que j'ai vues pour implémenter cela ne semblent pas vraiment rendre le problème plus difficile.

J'ai vu de nombreux tutoriels suggérant que le sel soit utilisé comme suit:

$hash =  md5($salt.$password)

Le raisonnement étant que le hachage ne correspond plus au mot de passe d'origine, mais à une combinaison du mot de passe et du sel. Mais dites $salt=fooet $password=baret $hash=3858f62230ac3c915f300c664312c63f. Maintenant, quelqu'un avec une table arc-en-ciel pourrait inverser le hachage et trouver l'entrée "foobar". Ils pourraient alors essayer toutes les combinaisons de mots de passe (f, fo, foo, ... oobar, obar, bar, ar, ar). Cela peut prendre quelques millisecondes de plus pour obtenir le mot de passe, mais pas grand-chose d'autre.

L'autre utilisation que j'ai vue concerne mon système Linux. Dans / etc / shadow, les mots de passe hachés sont réellement stockés avec le sel. Par exemple, un sel de « foo » et le mot de passe de « bar » serait hachage à ceci: $1$foo$te5SBM.7C25fFDu6bIRbX1. Si un pirate était en mesure de mettre la main sur ce fichier, je ne vois pas à quoi sert le sel, car le hachage inversé de te5SBM.7C25fFDu6bIRbXest connu pour contenir "foo".

Merci pour toute lumière que tout le monde peut apporter à ce sujet.

EDIT : Merci pour l'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 avant, c'est que je supposais qu'une table arc-en-ciel existait pour TOUS les hachages.

Un sel public ne rendra pas les attaques par dictionnaire plus difficiles lors de la fissuration d'un seul mot de passe. Comme vous l'avez souligné, l'attaquant a accès à la fois au mot de passe haché et au sel, donc lors de l'exécution de l'attaque par dictionnaire, il peut simplement utiliser le sel connu lorsqu'il tente de casser le mot de passe.

Un sel public fait deux choses: il rend plus long de casser une grande liste de mots de passe et il est impossible d'utiliser une table arc-en-ciel.

Pour comprendre le premier, imaginez un fichier de mots de passe unique contenant des centaines de noms d'utilisateurs 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 calculer "md5 (sel [a]. Tentative [0])", comparer avec l'entrée A, puis "md5 (sel [b]. Tenter [0])", comparer avec l'entrée B , etc. Maintenant, j'ai nbeaucoup de travail à faire, où nest le nombre de noms d'utilisateurs et de mots de passe contenus dans le fichier.

Pour comprendre le second, vous devez comprendre ce qu'est une table arc-en-ciel. Une table arc-en-ciel est une grande liste de hachages pré-calculés pour les mots de passe couramment utilisés. Imaginez à nouveau le fichier de mot de passe sans sels. Tout ce que j'ai à faire est de parcourir chaque ligne du fichier, de retirer le mot de passe haché et de le rechercher dans la table arc-en-ciel. Je n'ai jamais à calculer un seul hachage. Si la recherche 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 mot de passe est salé, la table arc-en-ciel devrait contenir un "sel. Mot de passe" pré-haché. Si le sel est suffisamment aléatoire, cela est très peu probable. Je vais probablement avoir des choses comme "bonjour" et "foobar" et "qwerty" dans ma liste de mots de passe pré-haché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é. Cela rendrait la table arc-en-ciel trop grande.

Ainsi, le sel réduit l'attaquant à un calcul par ligne par tentative, qui, lorsqu'il est associé à un mot de passe suffisamment long et suffisamment aléatoire, est (généralement parlant) non craquable.

Les autres réponses ne semblent pas répondre à vos malentendus sur le sujet, alors voici:

Deux utilisations différentes du sel

J'ai vu de nombreux tutoriels suggérant que le sel soit utilisé comme suit:

$hash = md5($salt.$password)

[...]

L'autre utilisation que j'ai vue concerne mon système Linux. Dans / etc / shadow, les mots de passe hachés sont réellement stockés avec le sel.

Vous toujours stocker le sel avec le mot de passe, car pour valider ce que l'utilisateur a entré dans votre base de données de mots de passe, vous devez combiner l'entrée avec le sel, le hacher et le comparer au hachage stocké.

Sécurité du hachage

Maintenant, quelqu'un avec une table arc-en-ciel pourrait inverser le hachage et trouver 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, au moins). Le hachage de "foo" et le hachage de "saltfoo" n'ont rien en commun. Changer même un bit dans l'entrée d'une fonction de hachage cryptographique devrait complètement changer 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" avec du sel. Vous devez tenir compte du sel dès le début.

C'est la raison pour laquelle vous avez d'abord besoin d'une table arc-en-ciel. Étant donné que vous ne pouvez pas accéder au mot de passe à partir du hachage, vous pré-calculez tous les hachages des mots de passe les plus utilisés, puis comparez vos hachages avec leurs hachages.

Qualité du sel

Mais dis $salt=foo

"foo" serait un choix de sel extrêmement pauvre. Normalement, vous utiliseriez une valeur aléatoire, encodée en ASCII.

De plus, chaque mot de passe a 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 l' un des hachages correspond à l'une des valeurs de sa base de données.

L'attaque

Si un pirate était en mesure de mettre la main sur ce dossier, je ne vois pas à quoi sert le sel,

Une attaque de table arc-en-ciel toujours besoin /etc/passwd(ou quelle que soit la base de données de mots de passe utilisée), ou bien comment comparer les hachages de la table arc-en-ciel aux hachages des mots de passe réels?

Quant à l'objectif: supposons que l'attaquant veuille construire une table arc-en-ciel pour 100 000 mots anglais et mots de passe courants (pensez «secret»). Sans sel, elle devrait précalculer 100 000 hachages. Même avec le sel UNIX traditionnel de 2 caractères (chacun est l'un des 64 choix :), [a–zA–Z0–9./]elle aurait à calculer et à stocker 4 096 000 000 de hachages ... une amélioration.

L'idée avec le sel est de le rendre beaucoup plus difficile à deviner avec la force brute qu'un mot de passe normal basé sur des caractères. Les tables arc-en-ciel sont souvent construites avec un jeu de caractères spécial à l'esprit et n'incluent pas toujours toutes les combinaisons possibles (bien qu'elles le puissent).

Ainsi, une bonne valeur de sel serait un entier aléatoire de 128 bits ou plus. C'est ce qui fait échouer les attaques arc-en-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 conçue 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 mots de passe à la fois.

Encore une autre grande 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 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 de mots de passe d'une grande société de logiciels dans le nord-ouest des États-Unis. Supposons qu'il contienne 30 000 entrées, dont 500 ont 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 e-mail de l'utilisateur au service informatique. Si les mots de passe ne sont pas salés, le pirate peut trouver la valeur hachée dans la base de données, puis simplement la mettre en correspondance pour lui donner accès aux 499 autres comptes.

Saler les mots de passe garantit que chacun des 500 comptes possède un unique (sel + mot de passe), générant un hachage différent pour chacun d'eux, et réduisant ainsi la violation à un seul compte. Et espérons, contre toute probabilité, que tout utilisateur suffisamment naïf pour écrire un mot de passe en texte brut dans un e-mail n'ait pas accès à l'API non documentée pour le prochain système d'exploitation.

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, de sorte que l'accès à un sel ne rendra pas la liste complète des hachages aussi facile à déchiffrer.

Pour stocker un mot de passe:

• Générez un long sel aléatoire à l'aide d'un CSPRNG.
• Ajoutez le sel au mot de passe et hachez-le avec une fonction de hachage cryptographique standard telle que SHA256.
• Enregistrez le sel et le hachage dans l'enregistrement de base de données de l'utilisateur.

Pour valider un mot de passe:

• Récupérez le sel et le hachage de l'utilisateur dans la base de données.
• Ajoutez le sel au mot de passe donné et hachez-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.

La raison pour laquelle un sel peut faire échouer une attaque de table arc-en-ciel est que pour n bits de sel, la table arc-en-ciel doit être 2 ^ n fois plus grande que la taille de la table sans le sel.

Votre exemple d'utilisation de «foo» comme sel pourrait rendre la table arc-en-ciel 16 millions de fois plus grande.

Étant donné l'exemple de Carl d'un sel de 128 bits, cela rend la table 2 ^ 128 fois plus grande - maintenant c'est grand - ou en d'autres termes, combien de temps avant que quelqu'un ait un stockage portable aussi gros?

La plupart des méthodes pour briser le chiffrement basé sur le hachage reposent sur des attaques par force brute. Une attaque arc-en-ciel est essentiellement une attaque de dictionnaire plus efficace, elle est conçue pour utiliser le faible coût du stockage numérique pour permettre la création d'une carte d'un sous-ensemble substantiel de mots de passe possibles vers des hachages et faciliter le mappage inverse. Ce type d'attaque fonctionne parce que de nombreux mots de passe ont tendance à être assez courts ou à utiliser l'un des quelques modèles de formats basés sur des mots.

De telles attaques sont inefficaces dans le cas où les mots de passe contiennent beaucoup plus de caractères et ne sont pas conformes aux formats basés sur des mots courants. Un utilisateur avec un mot de passe fort pour commencer ne sera pas vulnérable à ce style d'attaque. Malheureusement, beaucoup de gens ne choisissent pas de bons mots de passe. Mais il y a un compromis, vous pouvez améliorer le mot de passe d'un utilisateur en lui ajoutant des éléments indésirables. Alors maintenant, au lieu de "hunter2", leur mot de passe pourrait devenir effectivement "hunter2908! Fld2R75 {R7 /; 508PEzoz ^ U430", qui est un mot de passe beaucoup plus puissant. Cependant, comme vous devez maintenant stocker ce composant de mot de passe supplémentaire, cela réduit l'efficacité du mot de passe composite plus fort. En fin de compte, il y a toujours un avantage net à un tel schéma puisque maintenant chaque mot de passe, même les plus faibles, ne sont plus vulnérables à la même table de hachage / arc-en-ciel pré-calculée. Au lieu de cela, chaque entrée de hachage de mot de passe n'est vulnérable qu'à une table de hachage unique.

Supposons que vous ayez un site dont les exigences en matière de résistance des mots de passe sont faibles. Si vous n'utilisez aucun sel de mot de passe, tous vos hachages sont vulnérables aux tables de hachage pré-calculées, une personne ayant accès à vos hachages aurait donc accès aux mots de passe pour un grand pourcentage de vos utilisateurs (cependant, de nombreux mots de passe vulnérables utilisés, qui seraient un pourcentage substantiel). Si vous utilisez un sel de mot de passe constant, les tables de hachage précalculées ne sont plus utiles, donc quelqu'un devrait passer du temps à calculer une table de hachage personnalisée pour ce sel, mais il pourrait le faire de manière incrémentielle, en calculant des tables qui couvrent des permutations toujours plus grandes. de l'espace du problème. Les mots de passe les plus vulnérables (par exemple, les mots de passe simples basés sur des mots, les mots de passe alphanumériques très courts) seraient fissurés en quelques heures ou jours, les mots de passe moins vulnérables seraient fissurés après quelques semaines ou mois. Au fil du temps, un attaquant aurait accès aux mots de passe pour un pourcentage toujours croissant de vos utilisateurs. Si vous utilisez un sel unique pour chaque mot de passe, il faudrait des jours ou des mois pour accéder à chacun de ces mots de passe vulnérables.

Comme vous pouvez le voir, lorsque vous passez d'un sel sans sel à un sel constant à un sel unique, vous imposez une augmentation de plusieurs ordres de grandeur de l'effort pour casser les mots de passe vulnérables à chaque étape. Sans sel, les mots de passe les plus faibles de vos utilisateurs sont trivialement accessibles, avec un sel constant, ces mots de passe faibles sont accessibles à un attaquant déterminé, avec un sel unique, le coût d'accès aux mots de passe est si élevé que seul l'attaquant le plus déterminé pourrait y accéder à un minuscule sous-ensemble de mots de passe vulnérables, et seulement à grands frais.

C'est précisément la situation dans laquelle vous vous trouvez. Vous ne pouvez jamais protéger complètement les utilisateurs contre un mauvais choix de mot de passe, mais vous pouvez augmenter le coût de la compromission des mots de passe de vos utilisateurs à un niveau qui rend la compromission d'un seul mot de passe d'un utilisateur prohibitive.

L'un des objectifs du salage est de vaincre les tables de hachage précalculées. Si quelqu'un a une liste de millions de hachages pré-calculés, il ne pourra pas rechercher $ 1 $ foo $ te5SBM.7C25fFDu6bIRbX1 dans sa table même s'il connaît le hachage et le sel. Ils devront encore le forcer brutalement.

Un autre objectif, comme le mentionne Carl S, est de rendre plus coûteuse le forçage brutal d'une liste de hachages. (donnez-leur tous des sels différents)

Ces deux objectifs sont toujours atteints même si les sels sont publics.

Pour autant que je sache, le sel est destiné à rendre les attaques par dictionnaire plus difficiles.

C'est un fait connu que beaucoup de gens utiliseront des mots communs pour les mots de passe au lieu de chaînes apparemment aléatoires.

Ainsi, un pirate pourrait utiliser cela à son avantage au lieu d'utiliser simplement la force brute. Il ne recherchera pas les mots de passe comme aaa, aab, aac ... mais utilisera à la place des mots et des mots de passe courants (comme les noms des seigneurs des anneaux!;))

Donc, si mon mot de passe est Legolas, un pirate pourrait essayer cela et le deviner avec "quelques" essais. Cependant, si nous salons le mot de passe et qu'il devient fooLegolas, le hachage sera différent, donc l'attaque du dictionnaire sera infructueuse.

J'espère que cela pourra aider!

Je suppose que vous utilisez PHP --- md5 () fonction et les variables $ --- alors précédés, vous pouvez essayer de regarder cet article HOWTO Mot de passe Shadow spécialement le 11ème paragraphe.

De plus, vous avez peur d'utiliser des algorithmes de résumé de message, vous pouvez essayer de vrais algorithmes de chiffrement, tels que ceux fournis par le module mcrypt , ou des algorithmes de résumé de message plus puissants, tels que ceux qui fournissent le module mhash (sha1, sha256 et autres).

Je pense qu'un algorithme de résumé de message plus fort est un must. Il est connu que MD5 et SHA1 ont des problèmes de collision.