Re: retrouver le salt ???

Je vais faire avec un exemple.

Mettons que tu aies un compte sur le site dont le mot de passe est "1234". La BDD est leakée, tu retrouves ton compte avec le mot de passe haché associé : c6c4940b323ff81c66e02a02e0281c370c535008

Premier réflexe, tu regardes la longueur du haché. En l'occurence, c'est 20 octets, ce qui laisse présumer que le site a utilisé SHA-1. Tu essaies donc naïvement :

SHA1("1234") : 7110eda4d09e062aa5e4a390b0a572ac0d2c0220

Argl, pas le même résultat ! Tu lances alors une attaque brute-force, qui prendra plus ou moins de temps selon la longueur du sel :

for(s = 'a'; s < 'zzzzzzzzzzzzzzzzz'; ++s) {
 comparer(SHA1(s+"1234"), "c6c4940b323ff81c66e02a02e0281c370c535008");
}

et là, à un moment... bingo !

SHA1('azerty1234') = c6c4940b323ff81c66e02a02e0281c370c535008

Le sel est donc "azerty".

Ensuite, tu recalcules toute une rainbow table en prenant en compte ce sel (ce qui n'est pas très long) :

SHA1('azertysoleil') = e49603f863140f3444392730a685573d19f044df

etc etc.

Je suis d'accord avec toi que si le sel fait 100 caractères de long, ça sera beaucoup plus long à casser. Le vrai problème réside en fait dans ce que j'ai dit dans l'article :

A noter aussi que si l'attaquant a un accès plus important que la BDD (code source de la plateforme), il peut directement trouver le fichier dans lequel est stocké le sel.. Dans ce cas, on retrouve le même niveau de sécurité qu'en -2.

EDIT : j'oubliais le plus important : avec un sel constant, deux utilisateurs qui ont le même mot de passe auront le même haché ! Et ça c'est grave.