Sels secrets; pourquoi ralentissent-ils plus l'attaquant que moi?
Lorsqu'il étudie les diapositives de Dan Boneh pour 'Session Management and User Authentication' (2011) il mentionne 'sels secrets' sur la diapositive 'Autres défenses' (diapo 48 sur 58).
Il suggère de stocker dans la base de données:
Alice|SA|H(pwA , SA , rA)
Dans lequel Alice est le nom d'utilisateur, SA le sel associé à Alice et H(pwA , SA , rA) le résultat du hachage du mot de passe d'Alice pwA avec le sel et un petit valeur aléatoire rA.
Je ne comprends pas pourquoi l'ajout d'une valeur aléatoire courte r (8 bits) ralentit la vérification d'un facteur 128 alors qu'un attaquant est ralenti d'un facteur 256.
Cela serait probablement expliqué dans la conférence auditive que ces diapositives accompagnent.
Je suppose qu'il calcule cela en supposant que les utilisateurs entrent généralement leurs mots de passe corrects. Vous n'avez qu'à parcourir les options de r jusqu'à ce que vous en trouviez une qui produit un hachage correct.
Si vous avez reçu le mot de passe correct, vous rencontrerez un r qui produit un hachage correct; quand exactement cela se produira variera (car c'est aléatoire), mais en moyenne, vous passerez par la moitié des options totales (2 ** 8 = 256, 256/2 = 128) avant de le trouver.
Cependant, l'attaquant essaiera généralement incorrect mots de passe. Cela signifie qu'ils devront essayer toutes les options de r, qui est le 256 complet.
Juste pour ajouter quelque chose de plus à réponse de Xiong :
En cas de compromission d'une base de données, un attaquant tentera de récupérer tous les mots de passe (ou au moins les plus intéressants), ce qui signifie qu'il doit essayer chaque mot de passe candidat avec chaque "sel secret" possible, ce qui est assez cher
Pendant ce temps, le serveur n'a qu'à parcourir le "sel secret" éventuel avec le mot de passe entré par l'utilisateur. Non seulement le mot de passe est susceptible d'être correct, mais il n'en est qu'un pour chaque connexion utilisateur
En plus de ce qui précède:
protection contre les Rainbow Tables et les attaques (distribuées) Bruteforce.
Les tables arc-en-ciel contiennent les résultats d'un hachage donné, ce qui signifie que vous en avez un pour un type de hachage donné (sha1 par exemple). Vous pouvez simplement rechercher le résultat et "décrypter" un ensemble de hachages assez facilement. Ce qui ne fonctionne pas si vous avez des blocs de hachage ou chaque hachage individuel sur lui-même salé.
Il en va de même pour les attaques distribuées Bruteforce. Si vous essayez de faire de l'ingénierie inverse/de deviner les résultats d'un hachage (en utilisant des failles de sécurité dans un algorithme de hachage), vous pouvez les utiliser pour accélérer des hachages similaires. L'utilisation de plusieurs machines (la partie distribuée) qui commencent à rechercher un autre décalage, augmente considérablement les chances de succès. Si le coup peut se produire n'importe où sur une plage donnée, la chance sur un coup augmente considérablement si vous commencez sur plusieurs décalages en même temps. De plus, tout hachage découvert peut à nouveau être testé par rapport aux autres hachages à l'intérieur de l'ensemble que vous essayez de brutaliser.
Tout cela est rendu inutile lorsque vous salez un hachage, car le résultat n'est plus linéaire, prévisible ou consultable.