Double Possible:
Besoin d'aide pour comprendre un mot de passe de selMise à 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 | saltChaque 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)Par conséquent, 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:
Les 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, en boucle les mots de passe communs et de hachage:
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 nextJ'espère que cela illustre mon point beaucoup mieux.
Compte tenu 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
Étant donné qu'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 dont la durée 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
Cela représente une longueur maximale de 7 caractères alpha-numériques, à moins de la moitié de la vitesse d'exécution de cité de la 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.
Réponses
Trop de publicités?
Ce qui n'empêche pas 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 arc-en-ciel de la table pour 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.
Pour être plus précis, une attaque par dictionnaire, c'est à dire une attaque où tous les mots dans une liste exhaustive sont essayé, n'est pas "impossible", mais il est peu pratique: chaque bit de sel double de la quantité de stockage et de calcul. Bien sûr, ceci n'est vrai que si le sel n'est pas connu de l'attaquant.
Ceci est différent de la 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 supplémentaire combinaisons de mots de passe dans votre attaque de dictionnaire. Avec un dictionnaire contenant 200 000 mots que vous aurez à faire
De 200 000 * 264 = 3.69 * 1024
les 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 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):
Assez Avec Les Tables Arc-En-Ciel: Ce Que Vous Devez Savoir Sur Les Régimes De Mot De Passe Sécurisé
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.
Le 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 des milliers de fois. Le "bcrypt" l'algorithme est similaire, en utilisant un processus itératif de dérivation de clé qui est lent.
Lorsque 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.
Touche-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").
Beaucoup d'utilisateurs sur StackOverflow se référer à 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 par utilisateur 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.
