La réponse est non évidemment !

Cette article fait suite à une publication d’un de mes collègues MVP, Olivier Dahan, à propos de la vulnérabilité du md5.

http://www.e-naxos.com/Blog/post/2012/01/07/La-fusee-de-Free-et-la-securite-informatique.aspx

Pour résumer, il est indiqué que le MD5 est très facilement crackable et que donc qu’il ne faut surtout plus l’utiliser dans les bases de données.

Voila la partie concernant la vulnérabilité du md5 :

si vous utilisez MD5 pour protéger des clés, des mots de passe, etc, sachez que cela ne sert à rien.

 

La leçon : vérifiez que vous n’utilisez pas MD5 dans vos applications (vous ou ceux qui vous ont précédé dans l’écriture des logiciels dont vous avez la charge). N’utilisez plus ce codage car tout le monde sait le percer rapidement.

 

La seconde leçon est plus malveillante : si vous tombez sur un fichier ou une base de données utilisant MD5 pour “planquer” des mots de passe ou des informations sensibles, hélas, vous savez maintenant comment décrypter tout cela et en faire éventuellement mauvais usage.

 

 

En effet, le MD5 à une vulnérabilité aujourd’hui, mais je vais essayer de démontrer pourquoi il ne faut pas s’inquiéter.

Qu’est ce le MD5 ?

MD5 (Message Digest 5) est un hashage, donc destructif, c’est pour résumer un moyen de calculer une clé par rapport à une donnée, dans tous les cas le MD5 fera 32 caractères hexadécimal.

Je vous laisse donc imaginer comment on pourrait « décrypter » un livre de Shakespeare à partir de son md5 (ou alors un peu comme dans les films où on arrive à zoomer 10000 fois sur une image de caméra de sécurité…)

Comment peut on retrouver la donnée d’origine depuis son md5 alors ?

Un des moyens pour de remonter à l’origine est aujourd’hui le brute forcing, c’est à dire : essayer tous les combinaisons de caractères qui peuvent exister et calculer leurs md5 pour le comparer, je vous laisse imager le temps nécessaire pour cela… A dans 10 siècles !

On peut toutefois aller un peu plus vite en utilisant un dictionnaire de mot existant, mais si la donnée d’origine n’est pas dedans, il est impossible de la retrouver. Cette méthode est encore moins fiable quand on sait que la majorité des sites utilisant le md5, « salt » la donnée auparavant. C’est à dire, que si votre mot de passe est « 1234″, on va lui ajouter d’autre caractères avant de le hasher : « 1234CeciEstLeSaltDeMonSiteWeb » et on calculera le md5 sur cette nouvelle chaine.

On peut aussi utiliser une rainbow table, c’est pour résumer une gigantesque base de données qui nous servira à prémacher le travail lors de la recherche. Pour vulgariser, on peut dire qu’au lieu de calculer les md5 d’un dictionnaire à chaque fois, on stocke le md5 résultat et on cherche ensuite dans ces résultats s’il n’y a pas un md5 qui vaut la valeur que l’on cherche. Encore une fois, si le site utilise un grand SALT et que le mot de passe n’est pas « simple », c’est quasi impossible de le retrouver (à moins d’avoir un md5 d’un mot simple qui vaut la même valeur que le votre).

C’est avec cette dernière méthode qu’à été trouvé une correspondance au md5 « efb7929e6a5b7dcc6ebb79aa3c45af13″, qui est « jesaispas ». Mais ce dernier n’a été trouvé que parce qu’il appartenait au dictionnaire ayant servi à créer la rainbow table. Si ce dernier avait été « salté » ou jesaispas322, il n’aurait pas été possible de le trouver (il se peut même que la donnée source était autre chose mais que jesaispas avait le même md5, même si la proba est supra faible vu la simplicité de la donnée )

Mais il faut alors que j’utilise une autre méthode ?

Non.

Quelque soit le hashage que vous allez choisir, les trois méthodes précédentes seront toujours aussi fiable (enfin peu fiable). Que ce soit le brute forcing, le dictionnaire ou la rainbow table, on a toujours utilisé le sens « donnée source » -> « hash » et non l’inverse !!!!

Mais je suis sur que le MD5 est vulnérable !

Oui en effet le MD5 a une vulnérabilité, mais pas du tout dans le domaine qui nous concerne (stockage de mot de passe dans une base de données).

Une faille a été trouvée en 1996 puis amélioré fin 2004 concernant la possibilité de trouver des collisions MD5 (c’est-à-dire des blocs de données différents possédant la même MD5).

Ahh je l’avais dit !

Non, car en fait une collision est la possibilité à partir d’une donnée (mon mot de passe par exemple), de trouver une autre donnée ayant le même md5 !

Pour simplifier, imaginons que mon hashage n’est plus le md5, mais l’addition des valeurs des caractères de ma chaine, je vais pouvoir faire des collisions en inversant l’ordre des lettres car le résultat de l’addition de mes caractères sera toujours pareil.

En beaucoup plus complexe (mais sexy) c’est ce que l’on sait faire pour le MD5 (et aussi pour le SHA1).

Comme je l’ai préciser, pour calculer une collision il faut la donnée d’origine, c’est à dire que si je veux utiliser cela pour trouver un mot de passe dans une base de données, il me faut au préalable… le mot de passe que je cherche

Il est toujours impossible de forger des données ayant un MD5 précis. 

Donc à quoi sert une collision ?

La faille de la collision peut servir par exemple de changer quelques bits dans la donnée et d’avoir le même MD5 au final, avec notamment l’intégration d’ »invariant md5″, soit, un lot de données qui ne feront pas évoluer le md5 après inclusion. On trouve parfois des fichiers en téléchargement accompagné de leurs md5 pour vérifier l’authenticité du fichier. Grâce à cette faille donc, je peux modifier le fichier et avoir le même md5. Sauf que je ne suis pas libre des données modifiées/ajoutées, il est donc difficile d’imaginer intégrer un virus ou autre dedans.

Conclusion

Le MD5 dans son utilisation de hashage de mots de passe n’est pas aujourd’hui vulnérable, du moins il l’est autant que tous les autres algorithmes de hashage existant ou futur.