Le 02/07/2013 à 22h 17

qu’est ce qu’il faut pas lire comme conneries sur le salage et les rainbow tables…

si le salage est bien fait, il faut une rainbow table par compte qu’on veut pirater, pas très efficace d’où l’utilité d’un salage.

Pour résumé:
un bon stockage des mots de passe se fait comme suit:

• mdp privé qui ne transite pas en clair sur le reseau
  


• sel aléatoire de grande dimention(xxxx bits) et unique par mdp, le sel est stocké en clair
  


• un fonction pour ajouter le sel au mdp (par exemple un xor bit à bit). La méthode n’est pas secrete, on s’en fout.
  


• une fonction à sens unique (hashage) robuste et de préférence lourde en calcul. Le plus lent c’est le mieux c’est. C’est encore mieux si on peut paramétrer la lenteur. (md5 = caca). Pas un secret non plus.
  
  bref seul le mdp est secret et doit le rester. Le reste c’est juste pour emmerder les hackeurs.
  
  pour casser le mdp en brute force, on teste tous les mdp. Avec salage, soit on teste les mdp et on ajoute le sel, soit on teste directement les mdp salés. Sauf que les mdp salés le sont sur xxxx bits et donc si on teste les mdp salés, pas question de réduire la recherche à 8charactères alphanumériques on est obligé de se tapper les 2^(xxxxbits) possibilités. Et si on se limite à 8 char alphanum, on travaille par sel et donc c’est du brute force par mdp ce qui n’est pas du tout efficace. D’où l’énorme importance du salage, à condition qu’il soit bien fait; si il est trop petit l’espace de recherche est réduit d’autant, si il n’est pas unique alors son intérêt disparaît. Le fait qu’il soit en clair ne change rien.
  
  Les rainbows tables ne sont qu’un compromis entre stockage et calcul dans la résolution par brute force. Si on calcule tout, pas besoin de stockage et si on stocke tout, pas besoin de calcul. Le problème c’est que les calculs sont lourds et les faire à l’avance en stockant mdp+hash est plus économique, problème on ne peut pas tout stocker car bcp trop volumineux. D’où rainbow table, qui sont un compromis.
  Mais les rainbow tables ne tiennent pas compte du salage, donc une base de donnée avec salage rend inefficace ces tables.
  
  Bref je ne comprends pas pourquoi les grosses boites ne mettent pas automatiquement en œuvre le salage + key steching (genre bcrypt) + mdp longs acceptant tous les caractères.
  Surtout ces limites incompréhensible le longueur où le mdp est parfois tronqué à l’insu de l’utilisateur! Alors que la longueur de mdp est ce qui importe le plus dans sa robustesse.