Fonction de hachage et fonction de chiffrement.
C’est une erreur commune de croire que md5, sha1 et ses équivalents plus solides, sont des fonction de chiffrement. En effet, lorsque les mots de passe ne sont pas stockés en clair, il le sont souvent sous la forme d’un condensat (hash), et ce en se basant sur la propriété suivante : la fonction de hachage est une fonction à sens unique.
A partir du mot de passe, on peut obtenir le hash, mais pas l’inverse (les collisions c’est une autre histoire 😉 ). Donc, si un attaquant obtient le hash, il ne pourra rien faire avec, puisque ce n’est pas le mot de passe !
Et là c’est le drame…
En effet, bien qu’en théorie on ne puisse retrouver de façon formelle le mot de passe à partir du hash, il est toujours possible d’effectuer une attaque par force brute à l’aide d’un outil comme John The Ripper.
En essayant toutes les combinaisons possibles de mots de passes et en passant ces combinaisons dans la fonction de hachage approprié, l’attaquant peut retrouver le mot de passe !!!
« Mais alors, pourquoi n’utilise-t-on pas de fonction de chiffrement !!! » me direz vous…
- la crypto c’est compliqué : forcément, quand pour vous enseigner l’usage de la cryptographie, on vous bassine avec la théorie mathématique qui en est à l’origine… ça ne donne pas envie.
- la crypto c’est lent : quand on doit traiter plusieurs milliers d’opérations de login, on veut des fonctions rapides, et les fonctions de hachage sont bien plus rapides que celles de chiffrement.
- on a toujours fait ainsi : sur bien des systèmes, les mots de passe ont toujours été stockés sous forme de condensat, car à l’époque on avait pas la puissance nécessaire pour bruteforcer le hash. C’etait bien suffisant.
Sauf que les temps ont changé… mais pas les habitudes.
La solution : mettez y un peu de SEL.
Lorsque vous souhaitez stocker le mot de passe d’un utilisateur, utilisez la fonction de hash comme ceci : hash(« mot-de-passe » + « sel »)
Si jamais un attaquant tombe sur un hash, et qu’il le casse, il se retrouvera alors avec une chaine qui sera la concaténation du mot de passe et du sel ce qui allongera la durée nécessaire au cassage du mot de passe, et ajoutera de la complexité au mot de passe lui même, rendant bien plus longue sa découverte.
2 réponses sur « Ne confondons pas (fonction de hachage et de chiffrement) ! »
Attention le hash n'est pas forcément un morceau aléatoire (ou pas) rajouté au texte à hacher.
Il peut être un vecteur d'initialisation de la fonction de hash.
http://en.wikipedia.org/wiki/Salt_%28cryptography%29
De plus sur une attaque par bruteforce ça ne change pas grand chose si le sel est connu.
Mais ça bloque les attaques par rainbow tables.
Par exemple en WPA le ssid est utilisé comme vecteur d'initialisation. C'est pour cela qu'il existe des tables spécifiques pour netgear, orange, linksys, … et autres noms de ssid répandus.
Autre exemple le ms-cache hash dépend du nom de l'utilisateur. Les seules tables qui tournent sont faites pour "administrator".
Si les mots de passe sont stockés sous forme de hash et non chiffrés, c'est qu'il ne faut pas de clé pour les générer. Ainsi le client peut générer son hash et ne jamais avoir à envoyer son mot de passe en clair.
Si l'attaquant récupère un hash il pourra l'utiliser dans certains mécanismes de challenge-response basés sur le hash… C'est le cas dans Windows ! (cf. pass-the-hash)
Il suffit en effet de récupérer le hash d'un utilisateur pour accéder à ces partages réseau sur d'autres serveurs et d'avoir les mêmes droits que lui dans l'environnement AD.
http://www.sans.org/reading_room/whitepapers/testing/rss/why_crack_when_you_can_pass_the_hash_33219
je m'adressait plus particulièrement aux développeurs d'applications web, on on croise bien trop souvent des bases remplies de mots de passe en claire ou simplement hachés lors de pen-tests.
le sel bloque aussi les attaques par dictionnaire dans une certaine mesure 🙂