Comment le mot de passe sel aide-t-il contre une attaque de table Rainbow?
J'ai du mal à comprendre le but d'un sel pour un mot de passe. Je crois comprendre que l’utilisation principale est de gêner une attaque contre la table Rainbow. Cependant, les méthodes que j'ai vues pour implémenter ceci 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 correspond maintenant non pas au mot de passe d'origine, mais à une combinaison du mot de passe et du sel. Mais disons $salt=foo et $password=bar et $hash=3858f62230ac3c915f300c664312c63f. Maintenant, quelqu'un avec une table Rainbow pourrait inverser le hachage et proposer l'entrée "foobar". Ils pourraient alors essayer toutes les combinaisons de mots de passe (f, fo, foo, ... oobar, obar, bar, ar, ar). Quelques millisecondes supplémentaires peuvent être nécessaires pour obtenir le mot de passe, mais pas grand chose d'autre.
L'autre utilisation que j'ai vue est sur mon système Linux. Dans le/etc/shadow, les mots de passe hachés sont réellement stockés avec le sel. Par exemple, un "sel" de "foo" et un mot de passe de "bar" aurait pour résultat: $1$foo$te5SBM.7C25fFDu6bIRbX1. Si un pirate informatique parvient à 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, quiconque peut nous éclairer à ce sujet.
EDIT : Merci pour l'aide. Pour résumer ce que je comprends, le sel rend le mot de passe haché plus complexe, le rendant ainsi beaucoup moins susceptible d'exister dans une table Rainbow précalculée. Ce que j’avais mal compris auparavant, c’était que j’imaginais qu’une table Rainbow existait pour TOUS les hachages.
Un sel public va pas rendre les attaques par dictionnaire plus difficiles lorsque l'on déchiffre un seul mot de passe. Comme vous l'avez indiqué, l'attaquant a accès au mot de passe haché et au sel. Ainsi, lors de l'attaque par dictionnaire, il peut simplement utiliser le sel connu pour tenter de déchiffrer le mot de passe.
Un sel public fait deux choses: il est plus fastidieux de déchiffrer une longue liste de mots de passe et il est impossible d'utiliser une table Rainbow.
Pour comprendre le premier, imaginez un fichier de mot de passe unique contenant 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 n'importe où. Si des sels sont présents, je dois alors calculer "md5 (sel [a]. Tentative [0])", comparer à l'entrée A, puis "md5 (sel [b]. Tentative [0])", comparer à 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 le second, vous devez comprendre ce qu’est une table Rainbow. Une table Rainbow est une longue liste de hachages pré-calculés pour les mots de passe couramment 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 table Rainbow. Je n'ai jamais à calculer un seul hash. 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 la résolution du problème.
Mais si le fichier de mots de passe est salé, la table Rainbow devra contenir "sel. Mot de passe" pré-haché. Si le sel est suffisamment aléatoire, cela est très peu probable. J'aurai probablement des mots tels que "bonjour", "foobar" et "qwerty" dans ma liste de mots de passe pré-hachés couramment utilisés (la table Rainbow), mais je ne vais pas utiliser des mots tels que "jX95psDZhello" ou "LPgB0sdgxfoobar" ou "dZVUABJtqwerty" pré-calculé. Cela rendrait la table Rainbow prohibitive.
Ainsi, le sel réduit l'attaquant à un calcul par ligne et par tentative, ce qui, associé à un mot de passe suffisamment long et aléatoire, est (généralement) insaisissable.
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 est sur mon système Linux. Dans le/etc/shadow, les mots de passe hachés sont en réalité stockés avec le sel.
Vous toujours devez 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 à celui stocké. hacher.
Sécurité du hash
Maintenant, quelqu'un avec une table Rainbow pourrait inverser le hachage et proposer l'entrée "foobar".
[...]
depuis le hachage inverse de te5SBM.7C25fFDu6bIRbX est connu pour contenir "foo".
Il n'est pas possible d'inverser le hachage en tant que tel (du moins en théorie). Le hachage de "foo" et le hachage de "saltfoo" 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 Rainbow avec les mots de passe communs et ensuite la "mettre à jour" avec un peu de sel. Vous devez prendre en compte le sel dès le début.
C’est la raison pour laquelle vous avez d’abord besoin d’une table Rainbow. Étant donné que vous ne pouvez pas obtenir le mot de passe à partir du hachage, vous calculez tous les hachages des mots de passe les plus probables, puis comparez vos hachages à leurs hachages.
Qualité du sel
Mais disons
$salt=foo
"foo" serait un extrêmement mauvais choix de sel. Normalement, vous utiliseriez une valeur aléatoire, codée en ASCII.
En outre, 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 un des hachages correspond à l'une des valeurs de sa base de données.
L'attaque
Si un pirate informatique parvient à mettre la main sur ce fichier, je ne vois pas à quoi sert le sel,
Une attaque de table Rainbow toujours a besoin de /etc/passwd (ou la base de données de mots de passe utilisée), ou comment compareriez-vous les hachages de la table Rainbow aux hachages des mots de passe réels?
En ce qui concerne le but: supposons que l'attaquant veuille créer une table Rainbow pour 100 000 mots anglais et mots de passe usuels couramment utilisés (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 possibles: [a–zA–Z0–9./]), elle devrait calculer et stocker 4 096 000 000 de hachages ... un progrès considérable.
L'idée avec Salt est qu'il est beaucoup plus difficile de deviner avec la force brute qu'avec un mot de passe normal basé sur des caractères. Les tables arc-en-ciel sont souvent construites avec un caractère spécial, et n'incluent pas toujours toutes combinaisons possibles (bien qu'elles puissent).
Une bonne valeur de sel serait donc un entier aléatoire de 128 bits ou plus. C'est ce qui fait échouer les attaques de Rainbow-table. En utilisant une valeur de sel différente pour chaque mot de passe stocké, vous vous assurez également qu'une table Rainbow 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. mots de passe à la fois.
Encore une autre bonne question, avec beaucoup de réponses très réfléchies - +1 à SO!
Un petit point que je n'ai pas vu explicitement, c'est qu'en ajoutant un sel aléatoire à chaque mot de passe, vous garantissez pratiquement que deux les utilisateurs qui choisissent 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 entreprise de logiciels du 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 informatique parvienne à obtenir ce mot de passe, par exemple en le lisant dans un courrier électronique de l'utilisateur au service informatique. Si les mots de passe ne sont pas salés, le pirate informatique peut trouver la valeur hachée dans la base de données, puis il suffit simplement de lui appliquer un motif pour accéder aux 499 autres comptes.
Le salage des mots de passe garantit que chacun des 500 comptes a 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é, qu’un utilisateur assez naïf pour écrire un mot de passe en texte brut dans un courrier électronique n’aura pas accès à l’API non documentée du prochain système d’exploitation.
Je cherchais une bonne méthode pour appliquer les sels et trouvai cet excellent article avec un exemple de code:
http://crackstation.net/hashing-security.htm
L'auteur recommande l'utilisation de sels aléatoires par utilisateur, de sorte que l'accès à un sel ne rende pas la liste complète des hachages aussi facile à craquer.
Pour stocker un mot de passe:
- Générez un long sel aléatoire en utilisant 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 la base de données de l'utilisateur.
Pour valider un mot de passe:
- Récupérez le sel et le hachage de l'utilisateur de la base de données.
- Ajoutez le sel au mot de passe indiqué 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 contre une table Rainbow est que, pour n bits, la table Rainbow doit être 2 fois plus grande que la taille de la table sans le sel.
Votre exemple d'utilisation de "foo" en tant que sel pourrait rendre la table Rainbow 16 millions de fois plus grande.
Si Carl donne l'exemple d'un sel 128 bits, la table 2 est 128 fois plus grande - maintenant c'est énorme - ou autrement dit, combien de temps faudra-t-il avant que quelqu'un ait un stockage portable aussi gros?
La plupart des méthodes de rupture du cryptage basé sur le hachage reposent sur des attaques par force brute. Une attaque Rainbow est essentiellement une attaque par dictionnaire plus efficace, elle est conçue pour utiliser le stockage numérique à faible coût afin de permettre la création d’une carte d’un sous-ensemble substantiel de mots de passe possibles pour les hachages et de faciliter la 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 Word.
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 courants basés sur Word. 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 y ajoutant des fichiers indésirables. Alors maintenant, au lieu de "hunter2", leur mot de passe pourrait devenir efficacement "hunter2908! Fld2R75 {R7 /; 508PEzoz ^ U430", qui est un mot de passe beaucoup plus puissant. Cependant, étant donné que 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, un tel système présente toujours un avantage net, car chaque mot de passe, même le plus faible, n'est plus vulnérable à 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 est vulnérable uniquement à une table de hachage unique.
Supposons que votre site ait des exigences de force de mot de passe faibles. Si vous n'utilisez aucun mot de passe, vos hachages sont vulnérables aux tables de hachage pré-calculées, une personne ayant accès à vos hachages aurait ainsi accès aux mots de passe d'un grand pourcentage de vos utilisateurs (quel que soit le nombre de mots de passe vulnérables utilisés, ce qui serait un pourcentage substantiel). Si vous utilisez un sel de mot de passe constant, les tables de hachage pré-calculées ne sont plus utiles. Un utilisateur doit donc consacrer du temps à calculer une table de hachage personnalisée pour ce sel. Il peut le faire progressivement, cependant, les tables de calcul couvrant des permutations toujours plus grandes. de l'espace de problème. Les mots de passe les plus vulnérables (par exemple, des mots de passe simples basés sur Word, des mots de passe alphanumériques très courts) seraient déchirés en quelques heures ou quelques jours, tandis que les mots de passe moins vulnérables le seraient au bout de quelques semaines ou quelques mois. Au fil du temps, un attaquant aurait accès à des mots de passe pour un pourcentage toujours croissant de vos utilisateurs. Si vous utilisez un sel unique pour chaque mot de passe, il vous faudra des jours, voire des mois, pour accéder à chacun de ces mots de passe vulnérables.
Comme vous pouvez le constater, lorsque vous passez de sel sans sel à un sel constant, vous imposez un effort supplémentaire de plusieurs ordres de grandeur pour déchiffrer les mots de passe vulnérables à chaque étape. Sans un 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 tellement élevé que seul l'attaquant le plus déterminé peut accéder. à un petit sous-ensemble de mots de passe vulnérables, et alors seulement à grands frais.
C’est précisément la situation. Vous ne pouvez jamais protéger complètement les utilisateurs contre un choix de mot de passe médiocre, mais vous pouvez augmenter le coût de la compromission des mots de passe de vos utilisateurs à un niveau qui rend compromis le mot de passe même d’un utilisateur extrêmement prohibitif.
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 son tableau, même s'il connaît le hachage et le sel. Ils devront toujours 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.
Autant que je sache, le sel est destiné à rendre plus difficile les attaques par dictionnaire.
C'est un fait connu que beaucoup de gens vont utiliser des mots communs pour les mots de passe au lieu de chaînes apparemment aléatoires.
Ainsi, un pirate informatique pourrait utiliser cela à son avantage au lieu d'utiliser simplement la force brutale. Il ne cherchera pas de mots de passe comme aaa, aab, aac ... mais utilisera plutôt des mots et des mots de passe communs (comme les noms des seigneurs des anneaux!;))
Donc, si mon mot de passe est Legolas, un pirate informatique pourrait essayer cela et le deviner avec "quelques" tentatives. Cependant, si nous salons le mot de passe et qu'il devienne fooLegolas, le hachage sera différent, de sorte que l'attaque du dictionnaire échouera.
J'espère que ça t'as aidé!