Sel non aléatoire pour les hachages de mot de passe
MISE À JOUR: J'ai récemment appris de cette question que dans toute la discussion ci-dessous, j'ai (et je suis sûr que d'autres l'ont fait aussi) un peu déroutant: ce que j'appelle toujours une table Rainbow, est en fait appelé un table de hachage. Les tables arc-en-ciel sont des créatures plus complexes et sont en fait une variante de Hellman Hash Chains. Bien que je pense que la réponse est toujours la même (car cela ne se résume pas à la cryptanalyse), une partie de la discussion pourrait être un peu biaisée.
La question: " Que sont les tables Rainbow et comment sont-elles utilisées? "
En règle générale, je recommande toujours d'utiliser une valeur aléatoire cryptographiquement forte comme sel, à utiliser avec des fonctions de hachage (par exemple pour les mots de passe), comme pour se protéger contre les attaques de Rainbow Table.
Mais est-il réellement cryptographiquement nécessaire que le sel soit aléatoire? Une valeur unique (unique par utilisateur, par exemple userId) suffirait-elle à cet égard? Cela empêcherait en fait d'utiliser une seule table arc-en-ciel pour casser tous (ou la plupart) des mots de passe du système ...
Mais le manque d'entropie affaiblit-il vraiment la force cryptographique des fonctions de hachage?
Remarque, je ne demande pas pourquoi utiliser le sel, comment le protéger (il n'a pas besoin de l'être), utiliser un hachage constant unique (pas), ou quel type de fonction de hachage utiliser.
Juste si le sel a besoin d'entropie ou non.
Merci à tous pour les réponses jusqu'à présent, mais j'aimerais me concentrer sur les domaines que je connais (un peu) moins. Principalement des implications pour la cryptanalyse - j'apprécierais le plus si quelqu'un a une entrée du PoV crypto-mathématique.
De plus, s'il y a des vecteurs supplémentaires qui n'avaient pas été pris en compte, c'est une excellente entrée également (voir le point @Dave Sherohman sur plusieurs systèmes).
Au-delà de cela, si vous avez une théorie, une idée ou une meilleure pratique - veuillez l'étayer avec des preuves, un scénario d'attaque ou des preuves empiriques. Ou même des considérations valables pour des compromis acceptables ... Je connais les meilleures pratiques (capital B capital P) sur le sujet, je voudrais prouver quelle valeur cela fournit réellement.
EDIT: Quelques très bonnes réponses ici, mais je pense que comme @Dave le dit, cela se résume à Rainbow Tables pour les noms d'utilisateur courants ... et les noms moins communs possibles aussi. Cependant, que se passe-t-il si mes noms d'utilisateur sont uniques au monde? Pas nécessairement unique pour mon système, mais pour chaque utilisateur - par exemple adresse électronique.
Il n'y aurait aucune incitation à créer un RT pour un seul utilisateur (comme @Dave l'a souligné, le sel n'est pas gardé secret), et cela empêcherait toujours le clustering. Seul problème serait que je pourrais avoir le même email et mot de passe sur un site différent - mais le sel ne l'empêcherait pas de toute façon.
Donc, cela revient à la cryptanalyse - IS l'entropie nécessaire, ou non? (Ma pensée actuelle est que ce n'est pas nécessaire d'un point de vue de la cryptanalyse, mais c'est de autres raisons pratiques.)
Le sel est traditionnellement stocké en tant que préfixe du mot de passe haché. Cela le fait déjà savoir à tout attaquant ayant accès au hachage de mot de passe. L'utilisation du nom d'utilisateur comme sel ou non n'affecte pas ces connaissances et, par conséquent, cela n'aurait aucun effet sur la sécurité d'un seul système.
Cependant, l'utilisation du nom d'utilisateur ou de toute autre valeur contrôlée par l'utilisateur comme sel réduirait la sécurité entre les systèmes, car un utilisateur qui avait le même nom d'utilisateur et le même mot de passe sur plusieurs systèmes qui utilisent le même algorithme de hachage de mot de passe se retrouverait avec le même hachage de mot de passe sur chacun de ces systèmes. Je ne considère pas cela comme une responsabilité importante parce que, en tant qu'attaquant, j'essaierais les mots de passe qu'un compte cible est connu pour avoir utilisés sur d'autres systèmes avant d'essayer tout autre moyen de compromettre le compte. Des hachages identiques ne me diraient qu'à l'avance que le mot de passe connu fonctionnerait, ils ne rendraient pas l'attaque réelle plus facile. (Notez, cependant, qu'une comparaison rapide des bases de données de compte fournirait une liste de cibles de priorité plus élevée, car elle me dirait qui est et qui ne réutilise pas les mots de passe.)
Le plus grand danger de cette idée est que les noms d'utilisateur sont généralement réutilisés - à peu près n'importe quel site que vous souhaitez visiter aura un compte d'utilisateur nommé "Dave", par exemple, et "admin" ou "root" sont encore plus courants - ce qui rendrait la construction de tables Rainbow ciblant les utilisateurs portant ces noms communs est beaucoup plus simple et efficace.
Ces deux défauts pourraient être efficacement résolus en ajoutant une deuxième valeur de sel (fixe et cachée ou exposée comme du sel standard) au mot de passe avant de le hacher, mais, à ce stade, vous pouvez tout aussi bien utiliser du sel entropique standard de toute façon de travailler le nom d'utilisateur en elle.
Modifié pour ajouter: Beaucoup de gens parlent d'entropie et de l'importance de l'entropie dans le sel. C'est, mais pas pour la raison pour laquelle la plupart des commentaires semblent penser.
La pensée générale semble être que l'entropie est importante pour que le sel soit difficile à deviner pour un attaquant. C'est incorrect et, en fait, complètement hors de propos. Comme cela a été souligné à plusieurs reprises par diverses personnes, les attaques qui seront affectées par le sel ne peuvent être lancées que par une personne disposant de la base de données de mots de passe et une personne possédant la base de données de mots de passe peut simplement regarder pour voir quel est le sel de chaque compte. Qu'il soit devinable ou non, peu importe quand vous pouvez le rechercher trivialement.
La raison pour laquelle l'entropie est importante est d'éviter le regroupement des valeurs de sel. Si le sel est basé sur le nom d'utilisateur et que vous savez que la plupart des systèmes auront un compte nommé "root" ou "admin", alors vous pouvez créer une table Rainbow pour ces deux sels et il fissurera la plupart des systèmes. Si, d'autre part, un sel aléatoire de 16 bits est utilisé et que les valeurs aléatoires ont une distribution à peu près uniforme, alors vous avez besoin d'une table Rainbow pour tous les 2 ^ 16 sels possibles.
Il ne s'agit pas d'empêcher l'attaquant de savoir ce qu'est le sel d'un compte individuel, il ne s'agit pas de lui donner la grande cible grasse d'un seul sel qui sera utilisé sur une proportion substantielle de cibles potentielles.
L'utilisation d'un sel à haute entropie est absolument nécessaire pour stocker les mots de passe en toute sécurité.
Prenez mon nom d'utilisateur "gs" et ajoutez-le à mon mot de passe "MyPassword" donne gsMyPassword. Ceci est facilement cassé en utilisant une Rainbow-table car si le nom d'utilisateur n'a pas assez d'entropie, il se peut que cette valeur soit déjà stockée dans la Rainbow-table, surtout si le nom d'utilisateur est court.
Un autre problème concerne les attaques où vous savez qu'un utilisateur participe à deux services ou plus. Il existe de nombreux noms d'utilisateur courants, probablement les plus importants sont admin et root. Si quelqu'un créait une table arc-en-ciel contenant des sels avec les noms d'utilisateur les plus courants, il pouvait les utiliser pour compromettre les comptes.
Ils avaient un sel de 12 bits . 12 bits sont 4096 combinaisons différentes. Ce n'était pas assez sûr parce que autant d'informations peuvent être facilement stockées de nos jours . Il en va de même pour les 4096 noms d'utilisateur les plus utilisés. Il est probable que quelques-uns de vos utilisateurs choisissent un nom d'utilisateur appartenant aux noms d'utilisateur les plus courants.
J'ai trouvé ceci vérificateur de mot de passe qui fonctionne l'entropie de votre mot de passe. Le fait d'avoir une entropie plus petite dans les mots de passe (comme en utilisant des noms d'utilisateur) facilite beaucoup les tables arc-en-ciel car elles essaient de couvrir au moins tous les mots de passe avec une faible entropie, car elles sont plus susceptibles de se produire.
Il est vrai que le nom d'utilisateur seul peut être problématique car les gens peuvent partager des noms d'utilisateur entre différents sites Web. Mais cela ne devrait pas poser de problème si les utilisateurs avaient un nom différent sur chaque site Web. Alors pourquoi ne pas le rendre unique sur chaque site Web. Hachage le mot de passe un peu comme ça
fonction de hachage ("www.yourpage.com /" + nom d'utilisateur + "/" + mot de passe)
Cela devrait résoudre le problème. Je ne suis pas un maître de la cryptanalyse, mais je doute que le fait que nous n'utilisions pas d'entropie élevée rendrait le hachage plus faible.
J'aime utiliser les deux: un sel aléatoire par entropie à haute entropie, plus l'ID unique de l'enregistrement lui-même.
Bien que cela n'ajoute pas beaucoup à la sécurité contre les attaques par dictionnaire, etc., cela supprime le cas marginal où quelqu'un copie son sel et son hachage dans un autre enregistrement avec l'intention de remplacer le mot de passe par le leur.
(Certes, il est difficile de penser à une circonstance où cela s'applique, mais je ne vois aucun mal aux ceintures et bretelles en matière de sécurité.)
Je dirais que tant que le sel est différent pour chaque mot de passe, vous serez probablement d'accord. Le point essentiel est que vous ne pouvez pas utiliser la table Rainbow standard pour résoudre chaque mot de passe de la base de données. Donc, si vous appliquez un sel différent à chaque mot de passe (même s'il n'est pas aléatoire), l'attaquant devrait essentiellement calculer une nouvelle table Rainbow pour chaque mot de passe, car chaque mot de passe utilise un sel différent.
L'utilisation d'un sel avec plus d'entropie n'aide pas beaucoup, car l'attaquant dans ce cas est supposé avoir déjà la base de données. Puisque vous devez être capable de recréer le hachage, vous devez déjà savoir ce qu'est le sel. Vous devez donc stocker le sel ou les valeurs qui composent le sel dans votre fichier de toute façon. Dans des systèmes comme Linux, la méthode pour obtenir le sel est connue, donc il est inutile d'avoir un sel secret. Vous devez supposer que l'attaquant qui a vos valeurs de hachage connaît probablement aussi vos valeurs de sel.
La force d'une fonction de hachage n'est pas déterminée par son entrée!
L'utilisation d'un sel connu de l'attaquant rend évidemment la construction d'une table Rainbow (en particulier pour les noms d'utilisateur codés en dur comme root) plus attrayante, mais cela n'affaiblit pas le hachage . L'utilisation d'un sel inconnu de l'attaquant rendra le système plus difficile à attaquer.
La concaténation d'un nom d'utilisateur et d'un mot de passe peut toujours fournir une entrée pour une table Rainbow intelligente, donc l'utilisation d'un sel d'une série de caractères pseudo-aléatoires, stockés avec le mot de passe haché est probablement une meilleure idée. Par exemple, si j'avais le nom d'utilisateur "potato" et le mot de passe "beer", l'entrée concaténée pour votre hachage est "potatobeer", qui est une entrée raisonnable pour une table Rainbow.
Changer le sel à chaque fois que l'utilisateur change son mot de passe pourrait aider à vaincre les attaques prolongées, tout comme l'application d'une politique de mot de passe raisonnable, par exemple casse mixte, ponctuation, durée min, changement après n semaines.
Cependant, je dirais que votre choix d'algorithme de résumé est plus important. L'utilisation de SHA-512 va s'avérer plus pénible pour quelqu'un qui génère une table Rainbow que MD5, par exemple.
Si le sel est connu ou facilement devinable, vous n'avez pas augmenté la difficulté d'une attaque par dictionnaire. Il peut même être possible de créer une table Rainbow modifiée qui prend en compte un sel "constant".
L'utilisation de sels uniques augmente la difficulté des attaques par dictionnaire BULK.
Une valeur de sel unique et cryptographiquement forte serait idéale.
Le sel doit avoir autant d'entropie que possible pour garantir que si une valeur d'entrée donnée est hachée plusieurs fois, la valeur de hachage résultante sera, aussi proche que possible, toujours différente.
L'utilisation de valeurs de sel en constante évolution avec autant d'entropie que possible dans le sel garantira que la probabilité de hachage (par exemple, mot de passe + sel) produira des valeurs de hachage entièrement différentes.
Moins il y a d'entropie dans le sel, plus vous avez de chances de générer la même valeur de sel, et donc plus vous avez de chances de générer la même valeur de hachage.
C'est la nature de la valeur de hachage étant "constante" lorsque l'entrée est connue et "constante" qui permet aux attaques par dictionnaire ou aux tables Rainbow d'être si efficaces. En faisant varier autant que possible la valeur de hachage résultante (en utilisant des valeurs de sel d'entropie élevées), le hachage de la même entrée + sel aléatoire produira de nombreux résultats de valeur de hachage différents, ce qui vaincra (ou du moins réduira considérablement l'efficacité de) la table Rainbow. attaques.