Hash salé vs HMAC?
La plupart des discussions concernant les informations d'identification d'accès incluent des références au "hachage des mots de passe salés". Est-ce une autre façon de se référer à l'algorithme HMAC ou à une opération totalement différente? Différent ou non, pourquoi ne pas utiliser HMAC car il est facilement référencé à une norme publiée -FIPS198?
HMAC est un Message Authentication Code , qui est destiné à vérifier l'intégrité . C'est un genre de bête totalement différent.
Cependant, il se trouve que HMAC est construit sur des fonctions de hachage et peut être considéré comme un "hachage à clé" - une fonction de hachage avec une touche . Une clé n'est pas un sel (les clés sont secrètes, les sels ne le sont pas). Mais les caractéristiques uniques de HMAC en font un bloc de construction raisonnable pour d'autres fonctions, ce qui se passe dans PBKDF2 : c'est une fonction de dérivation de clé, généralement subvertie en hachage de mot de passe (un rôle pour lequel il semble adéquat). PBKDF2 inclut un sel et appelle en interne HMAC (plusieurs fois).
Un bon hachage de mot de passe doit être lent (de manière configurable) et inclure un sel . Ces caractéristiques ne sont pas faciles à obtenir et vous ne les obtiendrez pas d'un HMAC isolé (qui est rapide et n'utilise pas de sel).
Réponse courte:
En quelque sorte, mais pas vraiment. Un sel est simplement des données aléatoires ajoutées au message avant d'être hachées, dans le but de rendre le hachage produit par un message salé différent de tout ce qu'un attaquant peut avoir déjà calculé par lui-même avec le même message mais non salé (ou avec tout autre sel, d'ailleurs). Habituellement, les sels doivent être publics, afin de calculer légitimement le hachage correct d'un message secret à la demande. Un "sel secret" pour un message public, pour produire un hachage authentifié inviolable fonctionnerait en théorie, mais dans la pratique, nos fonctions de hachage sont imparfaites, et lorsqu'elles sont utilisées de cette manière, elles sont vulnérables aux attaques qui ajoutent des données au message d'origine et changer le hachage d'une manière prévisible (une "attaque d'extension de longueur").
Un HMAC incorpore des données secrètes supplémentaires sous la forme d'une clé. Cette clé est combinée avec le message d'une manière beaucoup plus profonde qu'un sel, et peut être utilisée en plus d'un simple sel du message. Le résultat final n'est pas vulnérable à la même attaque qu'un simple hachage avec un sel secret, et est donc une méthode beaucoup plus puissante pour produire un hachage authentifié.
Réponse plus longue:
Le but de base d'un hachage, tout hachage, est d'émuler un "Oracle aléatoire"; une boîte noire conceptuelle qui peut être donnée n'importe quelle message et produira une valeur vraiment aléatoire, vraiment unique digest pour l'identifier, et produira la même valeur aléatoire si jamais on lui donne la même message. Il existe un besoin pour ce type de fonction dans de nombreuses applications cryptographiques, toutes utilisant l'oracle aléatoire d'une manière subtilement différente. Malheureusement, les vrais oracles aléatoires n'existent pas, donc les fonctions de hachage, avec des faiblesses connues et inhérentes, doivent être suffisamment bonnes.
Un "mot de passe salé haché" est une utilisation. L'idée est que le message (le mot de passe) est un secret. La valeur hachée permet à quelqu'un de prouver à un système qu'il connaît le mot de passe correct, sans que le système doive se souvenir du mot de passe réel (le rendant vulnérable). Théoriquement, il suffit de donner le message à un Oracle aléatoire et d'en récupérer une valeur vraiment unique, mais parce que nous n'avons pas d'oracles aléatoires et que nous devons utiliser des fonctions de hachage à la place, le nombre de valeurs de digestion possibles par fonction de hachage peut produire est fini, donc théoriquement, on pourrait simplement trouver un message, n'importe quel message, qui produit chaque hachage souhaité, et se souvenir de tout cela afin qu'ils puissent rechercher un hachage observé et trouver un message qui le produira. Les sels rendent cette théorie beaucoup plus difficile, en obligeant un attaquant à calculer un hachage de chaque message possible avec chaque sel possible afin de garantir qu'il a la bonne combinaison de message et sel pour produire le hachage observé . La valeur de sel doit être une information publique, car le sel correct doit être utilisé lors du hachage légitime d'un message secret; cela la rend différente d'une clé, qui doit être gardée secrète pour garantir la sécurité du système.
L'observation de Thomas sur le hachage de mot de passe est cependant très correcte; les mots de passe choisis par les utilisateurs sont intrinsèquement peu entropiques et sont donc relativement faciles à deviner par la force brute, même lorsqu'ils sont salés. Pour décourager cela, une sécurité supplémentaire est requise, qui se présente généralement sous la forme d'un "étirement des clés"; une transformation coûteuse en calcul est ajoutée, pour ralentir la production d'un seul hachage (pas si lent qu'il affecterait les utilisateurs légitimes). Le travail supplémentaire pour chaque hachage fait répéter le calcul de hachage des centaines de milliers de fois pour forcer un mot de passe par une force brute une situation intenable pour un attaquant. Le salage est toujours nécessaire, car le moyen le plus simple d'éviter de faire ce travail à la demande est de le faire à l'avance et de se souvenir du résultat, comme avec un algorithme de hachage "plus rapide".
Un HMAC a un objectif subtilement différent. L'idée est que le message peut pas être secret; par conséquent, il peut très bien y avoir non secrets si un hachage de base était utilisé. Ce n'est pas une situation inouïe; les sommes de contrôle des fichiers sont disponibles gratuitement, tout comme les fichiers utilisés pour les générer, mais le hachage de la somme de contrôle est généralement protégé contre les modifications. Cependant, si le résumé ne peut pas être garanti en "lecture seule", par exemple s'il a été envoyé avec le message, le hachage n'a aucune valeur car il est trivialement modifié pour correspondre à tout message avec lequel il est envoyé. Un secret doit être ajouté au processus pour garantir que seule une personne connaissant le secret puisse utiliser le message (ou any message) pour produire un hachage correspondant. Un HMAC combine le message (qui peut encore être salé) avec une clé, nous donnant un tel secret.
Maintenant, il est juste de se demander pourquoi une valeur de sel ne peut pas simplement être gardée secrète en tant que clé et concaténée au message avant de la hacher avec une fonction de hachage sécurisée primitive. La réponse revient au point "nous n'avons pas d'oracles aléatoires". Si nous avions un Oracle aléatoire, nous pourrions garder une partie du message secret, et l'Oracle ne produirait jamais la même valeur (ou même une valeur prévisible) étant donné le reste du message, à moins que nous ne le recombinions avec le secret exact que nous ont refusé. Cependant, avec la plupart de nos fonctions de hachage "sécurisées" du monde réel, il existe une vulnérabilité connue permettant une attaque appelée "extension de longueur". Étant donné un condensé de hachage de longueur arbitraire et la connaissance de la primitive de hachage qui l'a produit, il est possible dans de nombreux cas de produire un hachage modifié qui correspondrait à l'ajout de données connues à la fin du message, sans connaître l'intégralité du message d'origine ( qui dans notre cas comprendrait un "sel secret" concaténé ou XORé). HMAC a été spécialement conçu pour vaincre cela, en combinant la clé avec le message plusieurs fois dans une opération de hachage imbriquée, ce qui entraîne un résumé sur lequel une extension de longueur ne peut pas être exécutée de manière triviale.