La distinction est arbitraire. Un algorithme sensible au sel fonctionne en prenant les données d'entrée et en les brouillant de différentes manières, et il n'y a pas de méthode pour insérer le sel qui soit plus ou moins "faux" que tout autre.

Essayer de créer un mot de passe un algorithme de traitement efficace sur un CPU à usage général mais qui ne s'adapte pas bien sur un GPU (ou un FPGA ou ASIC personnalisé) est un véritable sujet de recherche. C'est le but de scrypt, et on peut soutenir que bcrypt fait déjà du bon travail. L'idée ici est d'utiliser des accès dans des tables constamment modifiées; l'accès aux tables dans la RAM est quelque chose pour lequel les CPU à usage général sont bons, mais qui rend les choses difficiles pour le GPU (ils peuvent le faire, mais pas avec un parallélisme aussi complet que ce qui est généralement obtenu avec un GPU).

Oui, il y a une distinction valable à faire; vous auriez besoin d'un cryptologue pour vous dire à quel point la différence est significative.

Un "vrai sel" comme vous l'avez décrit est utilisé pour "perturber l'algorithme de chiffrement". Je comprends vaguement cela, mais pas assez bien pour décrire correctement. Qu'il suffise de dire qu'avec un vrai sel, le texte du mot de passe original est chiffré mais avec des sorties différentes selon la façon dont l'algorithme incorpore l'entrée salt (l'algorithme a (au moins deux) entrées, le sel et (séparément) le texte du mot de passe d'origine).

Un "faux sel" consiste à modifier le texte du mot de passe d'origine avec le sel avant de le chiffrer avec l'algorithme de cryptage. Par exemple, si mon mot de passe est "nezperce" et que mon sel est "qp", alors l'algorithme recevra le texte de mot de passe modifié "qpnezperce" à encoder. Si Alice essaie également d'utiliser le mot de passe "nezperce", mais a salt "w4", alors l'algorithme encodera le texte du mot de passe modifié "w4nezperce" pour elle. En conséquence, son hachage chiffré sera différent du mien, même si nous utilisons tous les deux le même mot de passe.

Les deux méthodes fournissent le principal avantage du sel; pour s'assurer que le même mot de passe n'est pas toujours chiffré de la même manière. L'utilisation de sels augmente la difficulté de monter une attaque de hachage précalculée (anciennement j'ai dit attaque par dictionnaire ou attaque par force brute, voir les commentaires).

Je pense qu'il y a d'autres avantages à utiliser un "vrai sel", tel comme une surcharge de calcul accrue (qui ralentit les attaques). Mais, encore une fois, vous auriez besoin de quelqu'un avec plus de compétences en crypto que moi pour savoir si c'est vrai ou non.

Je pense que l'avantage d'un "faux sel" est qu'il est plus facile à implémenter et nécessite moins de crypto avisé. Je sais que l'endroit où j'ai le plus souvent vu de faux sels, ce sont les applications Web gérant leur propre base de données d'authentification.

Comme Thomas l'a souligné, la notion générale de simplement appliquer le sel en tant que modification de l'algorithme de hachage ne vous apporte fondamentalement aucune protection supplémentaire. Cela peut obliger l'attaquant à adapter les attaques logicielles et matérielles existantes, mais cela peut également vous causer des ennuis si vous ne savez pas vraiment ce que vous faites.

Mais ils ont raté l'autre ancienne innovation dans le papier original sur le salage - ce qu'on appelle normalement un «poivre»: une clé personnalisée qui fait partie de l'implémentation, et non stockée avec les mots de passe. Je fais référence à la manière dont Morris et Thompson ont introduit ce concept également dans leur article fondateur sur Unix dans la discussion sur Le hachage de mot de passe ajouter du sel + du poivre ou est-ce que le sel est suffisant?

Un poivre a le avantage que vous pouvez l'utiliser en conjonction avec un sel, de sorte que même si quelqu'un vole la base de données de mots de passe (qui contient les sels), il devra également voler le poivre (peut-être incorporé dans l'application ou le code de la bibliothèque de hachage ou stocké sur un système complètement séparé) pour déchiffrer les mots de passe. Dans de nombreux cas, ce ne sera pas beaucoup plus difficile, mais dans certains cas, cela peut être beaucoup plus difficile.

Je ne connais pas les détails de l'implémentation de cryptage Unix d'origine. Mais cela ne me semble pas vraiment logique. Surtout en considérant quel est le but du salage des mots de passe en premier lieu. Je pense que si l'utilisation d'un sel change votre algorithme pour le rendre `` plus fort '', alors vous utilisez le mauvais algorithme en premier lieu.

J'étais également à la conférence et c'est moi qui me suis assis avec les deux cryptographes pendant la conférence. Le vrai sel par rapport à un faux sel m'a vraiment intrigué.Maintenant, pardonnez-moi car je n'ai pas mes notes devant moi, mais il y a une grande différence dans la sécurité du vrai sel par rapport à un faux sel.Un vrai sel altère le clé comme il entre dans le chiffrement par bloc, donc non seulement le texte en clair (mot de passe) est unique, la clé pour déterminer comment les itérations auront lieu est également unique.Maintenant, un faux sel modifie simplement le texte en clair (mot de passe) et la clé reste la même En ajustant l'algorithme, le vrai sel devient exponentiellement plus difficile à craquer qu'un faux sel.

Prenons donc un exemple pour décrire cela. Dans cet exemple, je vais utiliser un hachage MD5 (je ne me souviens pas si vous pouvez utiliser un vrai sel sur MD5, alors ne me flambez pas pour cela) avec à la fois un vrai sel et un faux sel. en utilisant CUDA-Multiforcer comme cracker de mot de passe GPU. Je me mettrais à courir contre le MD5 standard pour essayer de déchiffrer le mot de passe, mais depuis que j'ai salé le mot de passe, il pourrait fonctionner pour toujours en fonction du sel (vrai ou faux). Maintenant, une partie de la description qui m'a été donnée était la capacité de craquer le faux sel et comment il a fallu un peu plus de temps pour calculer / craquer en brisant le hachage en morceaux. Je n'ai pas suivi ce qu'ils disaient pour que je puisse être loin de la base avec cela. Maintenant supposons que nous avons pu acquérir le mot de passe salt (vrai de faux). En utilisant un faux sel, nous le saisissons simplement dans notre cracker de mot de passe et continuons à utiliser la force brute jusqu'à ce que nous puissions faire correspondre les hachages. Pas très difficile à faire et fonctionnera assez rapidement.

Maintenant, si nous utilisions un vrai sel, il serait exponentiellement plus difficile et plus long de casser les hachages. En utilisant un vrai sel, je devrais en fait réécrire une partie du CUDA-Multiforcer pour utiliser un vrai sel avec l'algorithme spécifique qui était utilisé. Rappelez-vous que cela change la clé du chiffrement, ce qui signifie que ce n'est pas seulement un simple changement de texte, c'est un changement d'algorithme, donc maintenant je dois modifier le code pour le faire. Bon, maintenant que nous avons changé le fonctionnement du cracker de mot de passe, nous rencontrons maintenant un problème de vitesse. Avec le changement de clé, il faut maintenant un peu plus de temps pour tester chaque mot de passe, car il change maintenant l'itération qu'il utilise pour chaque mot de passe forcé brutal. Ils m'avaient tous les deux donné des exemples de la différence de vitesse, et je pense qu'avec un faux sel, c'était environ 1 million par seconde, et un vrai sel était autour

La distinction entre le faux sel et le vrai sel ne fait une différence que si les algorithmes de hachage sont cachés à l'attaquant. un "sel réel" qui détermine une variation de l'algo de hachage dans un algo de hachage standard ouvert serait facilement implémenté par une attaque GPU / distribuée, puisque toutes les entrées sont connues de l'attaquant et donc le sous-algo peut facilement être déterminé avant

Le premier algorithme de hachage Unix pour les mots de passe (comme je le rappelle de Bell System V7) ne fournissait PAS l'algo pour le hachage de mot de passe - c'était la seule partie du système pour laquelle vous ne pouviez récupérez le fichier .o, où les universités ont pu obtenir le code source pour tout le reste.