Pourquoi ne sels attaques par dictionnaire "impossible"?
Mise à jour: Veuillez noter que je ne suis pas demande ce qu'est un sel est, ce qu'est un arc-en-ciel de la table est, ce qu'une attaque par dictionnaire est, ou quel est le but d'un sel. Je suis interrogation: Si vous connaissez les utilisateurs de sel et de hachage, n'est-il pas tout à fait facile de calculer leur mot de passe?
Je comprends le processus, et de mettre en œuvre moi-même dans certains de mes projets.
s = random salt
storedPassword = sha1(password + s)
Dans la base de données à stocker:
username | hashed_password | salt
Chaque mise en œuvre de salage j'ai vu, ajoute le sel, soit à la fin du mot de passe, ou le début:
hashed_Password = sha1(s + password )
hashed_Password = sha1(password + s)
Donc, une attaque de dictionnaire à partir d'un hacker qui vaut son sel (ha ha) serait tout simplement d'exécution de chaque mot-clé contre la stockées sels dans la commune de combinaisons énumérées ci-dessus.
Sûrement la mise en œuvre décrit ci-dessus ajoute simplement une autre étape pour le pirate, sans vraiment résoudre le problème sous-jacent? Quelles sont les alternatives à l'étape autour de ce problème ou suis-je à la mauvaise compréhension du problème?
La seule chose que je peux penser à faire est d'avoir un secret de fusion l'algorithme que lacets, le sel et le mot de passe ensemble dans un motif aléatoire, ou ajoute d'autres champs d'utilisateur pour le processus de hachage sens le pirate devrait avoir accès à la base de données ET le code de la dentelle pour une attaque par dictionnaire s'avérer fructueuse. (Mise à jour, comme l'a souligné dans les commentaires, il est préférable d'assumer le pirate a accès à toutes vos informations de sorte que ce n'est probablement pas le meilleur choix).
Permettez-moi de donner un exemple de la façon dont je propose un hacker aurait pirater un utilisateur de base de données avec une liste de mots de passe et les tables de hachage:
Données de notre piraté la base de données:
RawPassword (not stored) | Hashed | Salt
--------------------------------------------------------
letmein WEFLS... WEFOJFOFO...
Commune dictionnaire de mots de passe:
Common Password
--------------
letmein
12345
...
Pour chaque enregistrement de l'utilisateur, de la boucle de la commune de hachage des mots de passe et eux:
for each user in hacked_DB
salt = users_salt
hashed_pw = users_hashed_password
for each common_password
testhash = sha1(common_password + salt)
if testhash = hashed_pw then
//Match! Users password = common_password
//Lets visit the webpage and login now.
end if
next
next
J'espère que cela illustre mon point beaucoup mieux.
Donné de 10 000 mots de passe communs, et de 10 000 enregistrements d'utilisateur, nous aurions besoin de calculer 100 000 000 d'hachages de découvrir de nombreux mots de passe des utilisateurs que possible. Il peut prendre quelques heures, mais ce n'est pas vraiment un problème.
Mise à jour sur la Théorie de la Fissuration
Nous allons supposer que nous sommes corrompus hébergeur, qui a accès à une base de données de SHA1 les hachages et les sels, le long de avec votre algorithme pour les mélanger. La base de données de 10 000 enregistrements d'utilisateur.
Ce site prétend être capable de calculer 2,300,000,000 SHA1 hachages par seconde en utilisant le GPU. (Dans le monde réel de la situation sera probablement plus lent, mais pour l'instant, nous allons utiliser celle qui est indiquée à la figure).
(((95^4)/2300000000)/2)*10000 = 177
secondes
Donné une gamme complète de 95 caractères ASCII imprimables, avec une longueur maximale de 4 caractères, divisé par le taux de calcul (variable), divisé par 2 (en supposant que le temps moyen de découvrir le mot de passe en moyenne besoin de 50% de permutations) pour 10 000 utilisateurs il faudrait 177 secondes pour travailler tous les utilisateurs des mots de passe, où la longueur est <= 4.
Nous allons ajuster un peu de réalisme.
(((36^7)/1000000000)/2)*10000 = 2 jours
En supposant que le non respect de la casse, avec une longueur de mot de passe <= 7, seuls les caractères alphanumériques, il faudra 4 jours pour résoudre de 10 000 enregistrements d'utilisateur, et j'ai réduit de moitié la vitesse de l'algorithme afin de refléter les frais généraux et non idéal circonstance.
Il est important de reconnaître que ce linéaire d'une attaque de force brute, tous les calculs sont indépendants l'un de l'autre, donc c'est parfait tâche pour plusieurs systèmes à résoudre. (C'est à dire facile à mettre en place 2 ordinateurs exécutant une attaque à partir de différentes fins qui serait la moitié de la cours d'exécution en temps).
Compte tenu de l'affaire de manière récursive le hachage d'un mot de passe 1000 fois pour rendre cette tâche plus gourmand en ressources:
(((36^7) /1 000 000 000) /2) * 1000
secondes = 10.8839117 heures
Ce qui représente une longueur maximale de 7 caractères alpha-numériques, à moins de la moitié de la vitesse d'exécution de cité figure pour un utilisateur.
De façon récursive de hachage 1000 fois bloque efficacement une couverture de l'attaque, mais de manière ciblée les attaques sur les données de l'utilisateur sont toujours vulnérables.
- Le point entier dans le salage est pour vous empêcher d'être en mesure de regarder le hachage de mot de passe et de voir que plusieurs utilisateurs ont le même hash (et donc le même mot de passe). Sans salage vous pouvez simplement utiliser l'algorithme de hachage et de générer tous les possible de hachage et de procéder à une brute de recherche pour ce symbole. Puisque l'algorithme ne change jamais, il le rend prévisible pour les attaquants, saler juste rend beaucoup plus difficile.
- ici, il est discuté en détail : stackoverflow.com/questions/420843/...
- Merci @sera, je suppose que le point que je suis en train de faire, c'est qu'il est présenté comme un très sécurisée, alors qu'en réalité il ne l'est pas, il a juste obscurcit les données assez pour faire les pirates de l'emploi un peu plus irritant
- Oui, mais si vous utilisez un assez compliqué algorithme de hachage avec un bon pseudo-aléatoire de sel alors vous pouvez pousser la complexité de la résolution du problème dans les royaumes de l'impossibilité physique sur toute moderne/l'avenir matériel. 2^128 est un très gros chiffre!
- Si un pirate a accès à le sel + le hachage de mot de passe, il leur suffit d'exécuter tout le sel + dictionnaire des combinaisons de mots de passe, pour n dictionnaire des mots de passe, vous devez effectuer n hachage de calculs par compte d'utilisateur, beaucoup plus gourmand en ressources, mais parfaitement facile pour un ordinateur portable pour effectuer plus de quelques heures. Je ne sais pas si ma question est assez claire?
- Parce que les craquelins sont comme des limaces, et le sel assèche les muqueuses de la peau, et les tue.
- J'aime assez salés biscuits. Salé limaces, pas tellement.
- dans votre exemple de l'attaque. Si il n'y a pas de sel, puis l'attaquant peut faire "pour chaque mot de passe commun, hacher le mot de passe. - Il correspondre à un ou plusieurs utilisateurs? Oui, j'ai son mot de passe" - l'attaquant est capable de s'attaquer à tous les mots de passe "en parallèle", sans coût supplémentaire.
- Gullen - vous avez seulement la moitié de l'image. Sans sel, un attaquant ne serait pas utiliser la méthode que vous le démontrer dans "mise à Jour 2". Il suffit de faire une recherche dans une table et obtenir le mot de passe en O(1) O(log n) temps (n étant le nombre de candidats pour les mots de passe). Le sel est ce qui l'en empêche et l'oblige à recourir à l'O(n) approche de vous démontrer. Une autre technique (clé-renforcement) peut provoquer chaque tentative dans votre boucle de prendre une seconde, ce qui signifie qu'il va prendre 3 ans pour effectuer ces tests... et avec seulement 10k mots de passe, vous êtes susceptible de se fissurer à zéro les mots de passe en ce moment.
- Je ne savais pas que vous étiez en supposant que le sel avait été compromis. Alors que, techniquement, vous avez raison, le vrai problème, c'est que le hacker a compromis l'ensemble de la base de données avant de commencer. C'est un problème beaucoup plus vaste que le fait qu'il peut casser des mots de passe courants dans les 3 jours 😉 le Salage n'est pas destinée à prévenir de quoi vous parlez, mais plutôt pour empêcher les pirates d'accéder à tous les mot de passe de votre base de données en une seule fois. Il est - comme toutes les formes de chiffrement simplement une méthode pour gêner l'attaquant
- clé stengthening est un autre bon point. Faire de l'algorithme de hachage coûteuse en termes de calcul et de vous faire de nouveau craquage de moins en moins probable.
- Merci, quand dans le monde réel a une liste de mots de passe à été piraté sans avoir accès aux valeurs du sel? Il serait peut-être plus commun que j'assume, je me demandais.
- Merci également erickson, voulez-vous dire ressasser le résultat le dire 100 fois pour le rendre gourmand en ressources? Ou à l'aide d'un plus lourd algorithme de hachage? Je pouvais voir qu'elle fonctionne bien, mais pas l'article ou le guide que j'ai lu en ligne n'a jamais suggéré que.
- Gullen - je veux dire re-hachage le résultat de 2000 temps (que vous avez à considérer qu'un attaquant va utiliser quelque chose de rapide, pas de PHP), de sorte qu'il faut une bonne fraction de seconde pour calculer la valeur de hachage d'un mot de passe unique. Cela se retrouve dans la norme de dérivation de clé algorithmes PBKDF1 et PBKDF2, de PKCS #5, qui font de grands mot de passe de l'obscurcissement des algorithmes (la "clé dérivée" est le "hash"). Beaucoup d'utilisateurs sur référez-vous à cet article parce que c'était une réponse à Jeff Atwood.
- Généralement, supposons toujours que votre code et de votre base de données peut être la connaissance du public. Cela signifie que le fait d'avoir un moyen secret de mélanger le sel avec le mot de passe, comme vous le mentionnez, est une mauvaise idée, dans l'essentiel étant de la sécurité par l'obscurité. Non pas que j'ai de vous voir de la publicité pour elle, mais je voudrais juste mentionner pour obtenir des éclaircissements.
- BTW, bien sûr, vous assumez l'attaquant a tout. Supposons que l'attaquant est un corrompu de l'hébergement des employés de la société qui sous-évaluées sur la table utilisateur sur votre myprettypony.com fansite de sorte qu'il peut récupérer des mots de passe et de voir si elles fonctionnent sur les gens du citibank.com comptes. Avec un mot de passe système, il sera impossible pour ce type de récupérer tous les mots de passe.
- Merci Boris, mais beaucoup de la sécurité est la sécurité par l'obscurité n'est-ce pas? C'est essentiellement ce que un hash est?
- merci pour les précisions, vous pouvez le mettre dans une réponse, c'est exactement ce que je recherchais.
- excellent article, merci pour le lien
- Voir aussi: stackoverflow.com/questions/213380/... et stackoverflow.com/questions/1645161/... et stackoverflow.com/questions/536584/...
- Concernant la sécurité par l'obscurité: Non, il n'est pas. La sécurité Par l'Obscurité est à l'aide d'une faiblesse de la méthode et en supposant que vous pouvez empêcher les gens d'apprendre ce que cette methode est. Le point de sel est de conduire le coût moyen (dans le temps, la puissance de traitement, de l'espace disque, factures d'électricité, peu importe) de l'attaque supérieur à la valeur attendue à être gagné par la réussite ou de pousser la durée de réussite assez loin dans l'avenir qu'il n'a pas d'importance (par exemple, au-delà de la prochaine obligatoire de changement de mot de passe).
- merci mais j'étais sous l'impression de la définition de la sécurité par l'obscurité ne permet pas de couvrir la "faiblesse" de la solution? C'est à dire, ce n'est pas, par définition, necesserially faible. Votre remarque au sujet de la signification d'un secret de la méthode est correcte bien que, de mon point est, par exemple, est la clé publique de chiffrement de la STO parce que vous la méthode est de combiner un "secret key"?
- J'ai mis à jour la question avec quelques chiffres sur la fissure fois pour divers scénarios, jusqu'à présent, j'ai appris que récursive de hachage protège sur couverture de fissures, et j'espère que j'ai prouvé que, mais la question qui se pose maintenant est de savoir comment pouvons-nous protéger contre les attaques ciblées? Ce qui revient à l'utilisateur, et si vous avez besoin d'un 9 caractère de mot de passe avec un char spécial, et la sensibilité de cas vous serez à la recherche à (((95^9) / 1000000000) / 2) * 1000 secondes en années = 10 000 ans à se fissurer.
- Désolé, mais cette question n'est pas un doublon, donc j'ai voté pour la réouverture. Beaucoup de réponses semblent décrire ce qu'est un sel est, pourquoi il est là, qui ne traite pas de la question. Cette question est plus précis que ça.
- De Plus, nous sommes la génération discussion intéressante donc ce serait bien de le garder ouvert!
- "Évitez de poser des questions [...] nécessitent de longues discussions." -- La FAQ
Vous devez vous connecter pour publier un commentaire.
Oui, vous avez juste besoin de 3 jours pour sha1(sel | mot de passe). C'est pourquoi un bon mot de passe de stockage des algorithmes de 1000 itération de hachage: vous aurez besoin de 8 ans.
Il n'a pas arrêter les attaques de dictionnaire.
Ce qu'il fait, c'est d'arrêter quelqu'un qui parvient à obtenir une copie de votre fichier de mot de passe de l'aide d'un table arc-en-ciel à comprendre ce que les mots de passe sont des hachages.
Finalement, il peut être brute forcé, cependant. La réponse à la partie est de forcer vos utilisateurs de ne pas utiliser les mots du dictionnaire des mots de passe (exigences minimales d'au moins un chiffre ou un caractère spécial, par exemple).
Mise à jour:
J'aurais dû en parler plus tôt, mais certains (la plupart?) mot de passe systèmes d'utiliser un autre sel pour chaque mot de passe, probablement stocké avec le mot de passe lui-même. Cela rend une unique table arc-en-ciel inutiles. C'est de cette façon UNIX crypte de la bibliothèque fonctionne, moderne et UNIX-like avec des Systèmes d'exploitation ont étendu cette bibliothèque avec de nouveaux algorithmes de hachage.
Je sais pour un fait que le soutien pour SHA-256 et SHA-512 ont été ajoutés dans les plus récentes versions de GNU crypte.
srand (time(NULL));
par exemple.Pour être plus précis, un attaque par dictionnaire, c'est à dire une attaque où tous les mots dans une liste exhaustive sont essayé, n'est pas "impossible", mais il devient impossible: chaque peu de sel double de la quantité de stockage et de calcul.
Ce qui est différent de pré-calculé dictionnaire des attaques comme des attaques impliquant des rainbow tables où il n'est pas question de savoir si le sel est secret ou pas.
Exemple: Avec une version 64 bits de sel (c'est à dire 8 octets), vous devez vérifier 264 mot de passe supplémentaire pour les combinaisons de votre attaque de dictionnaire. Avec un dictionnaire contenant 200 000 mots que vous aurez à faire
tests dans le pire des cas - au lieu de 200 000 tests sans sel.
Un avantage supplémentaire de l'utilisation de sel est qu'un attaquant ne peut pas pré-calculer le hachage de mots de passe à partir de son dictionnaire. Il serait tout simplement de prendre trop de temps et/ou de l'espace.
Mise à jour
Votre mise à jour suppose que l'attaquant connaît déjà le sel (ou a été volé, il). Bien sûr, cela est différent de la situation. Néanmoins, il n'est pas possible pour l'attaquant d'utiliser un pré-calculé arc-en-ciel de la table. Ce qui importe ici est beaucoup de la vitesse de la fonction de hachage. Pour faire une attaque impossible, la fonction de hachage doit être lente. MD5 ou SHA ne sont pas de bons candidats car ils sont conçus pour être rapides, de meilleurs candidats pour les algorithmes de hachage sont Blowfish ou certaines variantes.
Mise à jour 2
Une bonne lecture sur la question de la sécurisation de vos mots de passe en général (ce qui va bien au-delà de la question d'origine, mais toujours intéressant):
Corollaire de l'article: Utilisation salé hachages créé avec bcrypt (basé sur Blowfish) ou Eksblowfish qui vous permet d'utiliser un configurables, le temps de faire le hachage lent.
Un dictionnaire est une structure où les valeurs sont indexées par des touches. Dans le cas d'une pré-calculées d'attaque de dictionnaire, chaque clé est une table de hachage, et la valeur correspondante est un mot de passe que les résultats dans la table de hachage. Avec un pré-calculé dictionnaire à la main, un attaquant peut "instantanément" recherche d'un mot de passe qui permettra de produire le nécessaire de hachage pour vous connecter.
Avec du sel, de l'espace nécessaire pour stocker le dictionnaire se développe rapidement... tellement rapidement, que d'essayer de calculer d'un dictionnaire de mots de passe devient vite inutile.
Le meilleur sels sont choisis au hasard à partir d'un chiffrement générateur de nombre aléatoire. Huit octets est une dimension pratique, et plus de 16 octets ne sert à rien.
Sel fait beaucoup plus que juste "faire un attaquant de travail plus irritant." Il élimine toute une classe d'attaque—l'utilisation de précalculées dictionnaires.
Un autre élément est nécessaire de sécuriser totalement les mots de passe, et qui est "la clé de renforcement." Un tour de SHA-1 n'est pas assez bon: un mot de passe sûr algorithme de hachage doit être très lente de calcul.
Beaucoup de gens utilisent PBKDF2, une fonction de dérivation de clé, qui alimente en retour les résultats de la fonction de hachage milliers de fois. Le "bcrypt" l'algorithme est similaire, en utilisant un processus itératif de dérivation de clé qui est lent.
Lors de l'opération hachage est très lente, une table précalculée devient de plus en plus souhaitable pour un attaquant. Mais bon le sel défaites qui approche.
Commentaires
Ci-dessous sont les commentaires que j'ai fait sur la question.
Sans sel, un attaquant ne serait pas utiliser la méthode présentée dans "mise à Jour 2". Il suffit de faire une recherche dans une pré-calculé de la table et obtenir le mot de passe en O(1) O(log n) temps (n étant le nombre de candidats pour les mots de passe). Le sel est ce qui l'en empêche et l'oblige à recourir à l'O(n) approche indiqué dans la section "mise à Jour 2".
Une fois réduite à un O(n) attaque, nous devons tenir compte de combien de temps chaque tentative prend. Clé de renforcement peut provoquer chaque tentative dans la boucle de prendre une seconde, ce qui signifie que le temps nécessaire pour tester 10k mots de passe sur les utilisateurs de 10k s'étend de 3 jours à 3 ans... et avec seulement 10k mots de passe, vous êtes susceptible de se fissurer à zéro les mots de passe en ce moment.
Vous avez à considérer qu'un attaquant va utiliser le plus rapide des outils qu'il peut, pas de PHP, donc des milliers d'itérations, plutôt que de 100, serait un bon paramètre de clé de renforcement. Il devrait prendre une grande fraction de seconde pour calculer la valeur de hachage d'un mot de passe unique.
Clé-le renforcement de la dérivation de clé algorithmes PBKDF1 et PBKDF2, de PKCS #5, qui font de grands mot de passe de l'obscurcissement des algorithmes (la "clé dérivée" est le "hash").
Un grand nombre d'utilisateurs sur StackOverflow reportez-vous à cet article parce que c'était une réponse à Jeff Atwood post sur les dangers de l'arc-en-ciel tables. Ce n'est pas mon préféré de l'article, mais il le fait de discuter de ces concepts plus en détail.
Bien sûr, vous assumez l'attaquant a tout: le sel, le hachage, le nom d'utilisateur. Supposons que l'attaquant est un corrompu de l'hébergement des employés de la société qui sous-évaluées sur la table utilisateur sur votre myprettypony.com site de fans. Il essaie de récupérer ces mots de passe, car il va tourner autour et de voir si votre poney fans utilisé le même mot de passe sur leur citibank.com comptes.
Avec un mot de passe système, il sera impossible pour ce type de récupérer tous les mots de passe.
Le point de salage est d'empêcher l'amortissement de l'attaquant de l'effort.
Sans sel, une seule table de précalculées de hachage entrées de mot de passe (par exemple MD5 de tous les alphanumérique 5 chaînes de caractères, facile à trouver en ligne) peut être utilisé sur chaque utilisateur dans chaque base de données dans le monde.
Avec un site spécifique du sel, l'attaquant a pour calculer le tableau lui-même et peut alors l'utiliser sur tous les utilisateurs du site.
Avec un utilisateur par le sel, l'attaquant doit dépenser cet effort pour chaque utilisateur séparément.
Bien sûr, ce n'est pas faire beaucoup pour protéger vraiment les mots de passe faibles tout droit sorti d'un dictionnaire, mais il protège raisonnablement des mots de passe forts à l'encontre de cet amortissement.
Également un plus imporatant point à l'aide d'un UTILISATEUR spécifique du sel empêche la détection de deux utilisateurs avec le MÊME mot de passe de leurs hashes correspondent. C'est pourquoi de nombreuses fois la valeur de hachage est de hachage(sel + nom d'utilisateur + mot de passe)
Si vous essayez de garder le hachage secret que l'attaquant ne peut pas vérifier le hash.
Modifier - simplement remarqué que le principal point a été évoqué dans un commentaire ci-dessus.
Sels sont mises en œuvre pour prévenir l'arc-en-ciel de la table des attaques. Un arc-en-ciel tableau est une liste de pré-calculé de tables de hachage, ce qui rend la traduction d'un hachage dans une phrase beaucoup plus simple. Vous devez comprendre que le salage n'est pas efficace comme un moderne de la prévention de la fissuration d'un mot de passe, sauf si nous avons un moderne algo de hachage.
Donc permet de dire que nous travaillons avec SHA1, profitant des récents exploits découvert avec cet algo, et permet de dire que nous avons un ordinateur à 1 000 000 de hachages/seconde, il faudrait 5,3 millions de millions de millions d'années pour trouver une collision, alors, oui, le php de travail de 300 une seconde, big woop, n'a pas vraiment d'importance. La raison pour laquelle nous le sel est parce que si quelqu'un n'a pris la peine de générer tous les courants du dictionnaire des phrases, (2^160 personnes, bienvenue à 2007 era exploits).
Voici donc une véritable base de données, avec 2 utilisateurs-je utiliser pour les tests et admin fins.
En fait, le salage régime est votre sha1(temps d'enregistrement de + nom d'utilisateur). Allez-y, dites-moi mon mot de passe, ce sont de vrais mots de passe en production. Vous pouvez même vous asseoir là et de hachage d'un mot de la liste en php. Go wild.
Je ne suis pas fou, je sais juste que c'est sécurisé. Pour le plaisir, le saké, le test du mot de passe est
test
.sha1(sha1(1281546174.065087 + test) + test) = 5872548f2abfef8cb729cac14bc979462798d023
Vous devez générer un ensemble de l'arc-en-ciel de la table perpended avec
27662aee8eee1cb5ab4917b09bdba31d091ab732
pour juste cet utilisateur. Cela signifie que je peux réellement permettre à mes mots de passe pour ne pas être compromis par un seul arc-en-ciel de la table, le pirate doit produire une rainbow table pour 27662aee8eee1cb5ab4917b09bdba31d091ab732 pour le test, et encore f3f7735311217529f2e020468004a2aa5b3dee7f pour briang. Pensez à les 5,3 millions de millions de millions d'années pour que toutes les tables de hachage. Pensez à la taille de stocker 2^80 hachages (c'est bien plus de 20 yottabytes), il ne va pas arriver.Ne pas confondre le salage comme un moyen de faire un hachage quelque chose que vous ne pouvez pas jamais décoder, c'est un moyen de prévenir un arc-en-ciel de la table de traduction de tous vos mots de passe utilisateur. Il est imposé à ce niveau de technologie.
L'idée derrière l'attaque de dictionnaire, c'est que vous prenez un hachage et de trouver le mot de passe, à partir de laquelle cette empreinte a été calculé, sans calcul de hachage. Maintenant faites la même chose avec salé mot de passe vous ne pouvez pas.
Pas à l'aide d'un sel rend le mot de passe recherche aussi facile que la recherche dans la base de données. L'ajout d'un sel faire attaquant effectuer le calcul de hachage de tous les mots de passe possibles, même pour le dictionnaire de fixer ce qui augmente considérablement le temps de l'attaque).
En termes plus simples: sans salage, chaque candidat mot de passe ne doivent être hachées une fois pour le vérifier à l'encontre de tous les utilisateurs, n'importe où dans le "connu de l'univers" (collection de compromis bases de données), dont le mot de passe est haché par le même algorithme. Avec le salage, si le nombre de valeurs du sel dépasse considérablement le nombre d'utilisateurs dans la rubrique "univers", chaque candidat mot de passe doit être haché séparément pour chaque utilisateur contre laquelle il sera testé.
Simplement mettre le salage n'empêche pas un hachage de l'attaque (bruteforce ou dictionnaire), et cela rend plus difficile; l'attaquant aurez besoin de trouver le salage de l'algorithme (qui, si mis en œuvre correctement, faire usage de plus d'itérations) ou bruteforce l'algo, qui, sauf très simple, est presque impossible. Saler également presque totalement les rejets de l'option de l'arc-en-ciel de la table de recherche...
Sel rend Table arc-en-ciel attaques beaucoup plus difficile car il rend une unique hachage de mot de passe beaucoup plus difficile à casser. Imaginez que vous avez un horrible mot de passe de juste le numéro 1. Un arc-en-ciel de la table de l'attaque de la fissure immédiatement.
Maintenant, imaginez que chaque mot de passe dans la base de données est salé, avec une longue valeur aléatoire de nombreux caractères aléatoires. Maintenant, votre mauvais mot de passe de "1" est stocké dans la base de données comme un hachage de 1, plus un tas de caractères aléatoires (le sel), donc dans cet exemple, l'arc-en-ciel de la table doit avoir la valeur de hachage pour quelque chose comme: 1.
Donc, en supposant que votre sel est quelque chose de sûr et aléatoire, dire ()%ISLDGHASKLU(%#%#, le pirate de l'arc-en-ciel table a besoin d'avoir une entrée pour 1*()%ISLDGHASKLU(*%#%#. Maintenant, à l'aide d'un arc-en-ciel de la table sur ce simple mot de passe n'est plus pratique.