À quel point serait-il difficile de casser des hachages bcrypt si le sel était inconnu?
(Ce n'est pas un doublon de la question liée à mon humble avis car il s'agit davantage des différences entre un sel et un mot de passe: les deux variables utilisées pour générer un hachage)
Supposons qu'un attaquant ait un accès hors ligne à une base de données dans laquelle les mots de passe sont hachés avec bcrypt (sans ajout de poivre). Les hachages ressemblent à:
$2y$10$H0mRpD2XJZDguAzxTehwzunRkjUR8lB3O4UGrAGLiqJuvnlWjFA7G
Dans lequel le sel est: H0mRpD2XJZDguAzxTehwzu et le hachage est nRkjUR8lB3O4UGrAGLiqJuvnlWjFA7G.
L'attaquant ne pourra pas exécuter une table Rainbow pour faire correspondre les hachages, mais elle pourrait calculer les mots de passe courants en utilisant le sel inclus, exécutant ainsi:
bcrypt("abcd1234", 10, "H0mRpD2XJZDguAzxTehwzu")
produira:
nRkjUR8lB3O4UGrAGLiqJuvnlWjFA7G
Et voilà! Elle pourrait parcourir tous les tests de base de données "abcd1234" et être en mesure d'identifier les utilisateurs qui utilisent ce mot de passe faible en quelques secondes/minutes.
Et si seulement le hachage nRkjUR8lB3O4UGrAGLiqJuvnlWjFA7G est stocké dans la base de données (sans sel)?
Si l'attaquant a le fort sentiment que l'utilisateur "abcdefg" pourrait utiliser le mot de passe "abcd1234", comment pourrait-il tester sa théorie hors ligne? Elle aurait besoin de deviner le sel. Comment pouvait-elle le faire? Existe-t-il une méthode plus simple que d'essayer chaque combinaison? Peut-être que dans ce cas précis, il n'y aura pas assez de motivation pour l'essayer. Mais que se passe-t-il si elle soupçonne que le système utilise le même sel pour tous les mots de passe (car certains hachages sont les mêmes)? Comment serait-il difficile pour elle de le casser?
MISE À JOUR
La réponse de Pélée est proche de ce que j'attendais. Je vais essayer de l'étendre (corrigez-moi si je me trompe):
Entropie:
Dans Bcrypt, un sel est généralement composé de 16 octets aléatoires (128 bits). Si nous comparons cela à un mot de passe de la même longueur, un sel aura une entropie plus importante qu'un mot de passe, car les mots de passe sont généralement limités à ce que l'utilisateur peut taper avec un clavier.
Ces 16 octets sont encodés en HEX (en utilisant Base64) et deviennent 22 de longueur. Si nous les comparons avec un mot de passe de 22 caractères, le mot de passe contiendra une plus grande entropie (car il peut inclure des symboles et l'alphabet complet).
Longueur:
Les sels de Bcrypt sont limités à 16 octets tandis que les mots de passe peuvent être limités à 72 octets, selon la mise en œuvre.
Collision:
2 sels différents généreront 2 hachages différents, et donc les mots de passe. Cependant, à un moment donné, 2 sels différents pourraient produire le même hachage en utilisant le même mot de passe et vice-versa. Quelle est la probabilité pour chacun de ces cas? C'est quelque chose que je devrais peut-être demander dans crypto.SE. Mais je le laisse ici au cas où quelqu'un aurait la réponse.
Conception:
L'algorithme a été conçu pour protéger les mots de passe et non les sels. Cela signifie que les sels ne sont pas censés être sûrs par conception, ce qui suggère qu'il pourrait y avoir un moyen de les obtenir sans les forcer brutalement.
Cas fictif:
Nous sommes habitués à la méthode du mot de passe utilisateur pour protéger l'accès à un système. Mais, et si quelque chose comme ça se produit (veuillez me montrer, c'est juste un exemple)?:
La société CauseWeWantItThatWay utilise des micropuces pour stocker une valeur unique de 22 caractères hexadécimaux (à utiliser comme sel). Chaque utilisateur générera un total de 5 mots de passe ou PIN chiffres (4 chiffres chacun, oui, ils sont paresseux) avec ce sel unique pour accéder à 5 systèmes différents.
Supposons maintenant que je sois affecté à l'un de ces systèmes et que je connais l'un de ces numéros PIN, et j'ai en quelque sorte accès à la base de données. Si le sel était inclus, il serait trivial de obtenir ces PIN numéros, mais sans le sel, je devrais le casser.
Je sais à quoi tu penses. La société a une implémentation de sécurité vraiment mauvaise (et ils devraient brûler en enfer). De plus, ils auraient pu utiliser le "sel" comme poivre à la place et laisser le sel au hasard. Donc ma question était, dans ce cas, ce serait la même chose pour ajouter un 22-hex-chars comme poivre que d'utiliser ceux comme sel? Selon Peleus, c'est la même chose (donc aucun raccourci n'existe pour obtenir le sel).
Après tout, tout le monde ne suit pas les recommandations et l'algorithme vous permet de définir le sel, ce qui rend ce type de scénario totalement possible (bien que ce ne soit pas si probable ni recommandé).
Je pense que vous avez mal compris le but d'un sel, parce que si vous compreniez ce qu'il est conçu pour vous, vous ne poseriez peut-être pas cette question. Le seul but est de fournir un niveau d'unicité à chaque mot de passe afin d'éviter que les tables précalculées ("tables arc-en-ciel") ne soient une forme d'attaque efficace.
Par conséquent, il n'est pas conçu pour être "secret" ou ajouter de l'entropie au mot de passe, et c'est pourquoi il est stocké avec le hachage du mot de passe. En fait, dans la plupart des cas, il ne peut pas être secret car l'application elle-même aura besoin d'accéder au sel afin de calculer le hachage correct du mot de passe. Il est très difficile d'autoriser l'accès à l'application, mais empêchez un attaquant qui aurait violé l'application d'obtenir le même privilège.
Quoi qu'il en soit, pour répondre à votre question réelle - dans un monde théorique où vous deviez "casser" le sel parce qu'il était inconnu et ne pouvait pas être récupéré pour une raison quelconque, ce serait exactement le même niveau de complexité que les mots de passe. Fondamentalement (espace de caractères) ^ (longueur).
Dans votre exemple, vous donnez un hachage de "H0mRpD2XJZDguAzxTehwzu". En supposant que les caractères alphanumériques en majuscules/minuscules représentent un espace de 62 caractères et une longueur de 22 caractères. D'où 62 ^ 22 = 3.397504e + 23 ans de suppositions en supposant 1 milliard de suppositions par seconde. En d'autres termes, non craquable (c'est même en supposant que le mot de passe est connu et que vous essayez simplement de deviner un sel à l'échelle du système).
Un sel est stocké à côté du mot de passe. Il n'y a pas de règle qui dit que cela DOIT être comme ça, mais c'est un résultat logique de la destination d'un sel. Construire une table Rainbow n'est pas une tâche triviale. Le point essentiel est que l'attaquant aurait besoin d'une table Rainbow distincte pour chaque mot de passe salé (auquel cas il est plus facile d'attaquer directement chaque hachage de mot de passe à la place).
Vous pouvez lire ne longue réponse sur le sel , ce qui devrait expliquer pourquoi il est inutile de le garder secret.
Si vous voulez inclure du sel secret, vous devriez lire ce qui est communément appelé un poivre , qui adds une clé secrète étendue à l'application dans vos mots de passe salés. Ceci pourrait vous protéger contre les violations partielles (telles que les compromissions de bases de données via, par exemple, l'injection SQL), mais n'aidera pas en cas de violations complètes du système, sauf si vous utilisez un module de sécurité matérielle (HSM) pour protéger la valeur du poivre.
Lorsqu'un attaquant ne connaît que le hachage et non le sel, il doit non seulement tester tous les mots de passe possibles, mais tous les mots de passe possibles avec tous les sels possibles. Avec des valeurs de sel longues et aléatoires, cela est pratiquement impossible.
Cependant, ce n'est pas un scénario réaliste. Lorsqu'un attaquant compromet un système, vous devez supposer qu'il a compromis la base de données des hachages et des sels. Il est impossible de séparer ces deux ensembles de données d'une manière ou d'une autre, car ils sont toujours utilisés ensemble.