Générateur de hash MD5

MD5 n’est pas affaibli, il est cassé : deux entrées différentes produisant la même empreinte se fabriquent délibérément, en quelques secondes, sur un ordinateur portable ordinaire. La première collision a été publiée en 2004 et la technique n’a fait que devenir moins chère. Aucun réglage, aucun sel et aucune longueur ne réparent cela.

Ce que cela ne veut pas dire, c’est que MD5 serait devenu imprévisible ou que les empreintes existantes auraient cessé de correspondre. Une collision est une chose qu’un attaquant construit ; ce n’est pas une chose qui arrive par accident. Cette distinction contient tout l’usage résiduel : MD5 est fini partout où quelqu’un pourrait chercher à vous tromper, et intact là où personne n’essaie.

Détecter une corruption accidentelle. Un fichier tronqué en transit ou dont un bit a basculé sur un disque défaillant ne produira pas le même MD5, puisque rien ne cherchait à ce qu’il le produise. La déduplication pour la même raison : deux fichiers identiques ont la même empreinte, et la probabilité que deux fichiers réels sans rapport entrent en collision par hasard reste astronomiquement faible.

Reproduire quelque chose qui existe déjà est l’autre usage, et c’est pour lui que la plupart des gens arrivent ici. Une clé de cache, un ETag, une URL Gravatar, une colonne choisie en base il y a quinze ans : l’algorithme n’est alors pas un choix, c’est un fait concernant un système avec lequel il faut s’entendre.

Les mots de passe. Stocker un mot de passe en MD5 — avec ou sans sel — relève de la négligence plutôt que du retard, parce que MD5 est rapide, et la rapidité est exactement ce qu’il ne faut pas pour un hash de mot de passe. Du matériel grand public essaie des milliards de candidats MD5 par seconde ; tout l’intérêt de bcrypt, scrypt et Argon2 est qu’on ne peut pas les presser.

Tout ce à quoi vous accordez confiance, également. Une signature, un certificat, un téléchargement dont l’éditeur veut que vous le vérifiiez, un token dont vous contrôlez l’intégrité. Dans chacun de ces cas il existe un adversaire qui gagne à provoquer une collision, et en provoquer une n’est pas difficile. Prenez SHA-256, qui est à une page d’ici.

MD5 prend des octets, et un texte n’est pas des octets tant qu’un encodage n’a pas été choisi. Cette page emploie l’UTF-8, qui est ce que contiennent massivement les fichiers, les bases de données et les corps de requête. Un système qui a stocké le même texte en Latin-1 ou en UTF-16 produira une empreinte différente pour ce qui ressemble à la même chaîne, et aucune des deux parties n’a tort.

C’est la raison habituelle pour laquelle deux MD5 « du même » texte diffèrent, et elle se voit tout de suite en français : un `é` pèse deux octets en UTF-8 et un seul en Latin-1, donc n’importe quel mot accentué suffit à faire diverger les deux empreintes tandis qu’un texte purement ASCII les fait coïncider. Avant de conclure qu’une implémentation est fautive, vérifiez l’encodage, puis le retour à la ligne final.

Un fichier texte se termine presque toujours par un saut de ligne, et un champ de saisie non. Hacher le contenu d’un fichier et hacher le même texte collé ici donne donc deux empreintes qui n’ont rien en commun, sans que quoi que ce soit soit cassé.

S’ajoute à cela la question des fins de ligne : `\r\n` sous Windows contre `\n` ailleurs. Un fichier passé par un dépôt Git configuré pour convertir automatiquement change d’octets sans changer de contenu apparent, et son MD5 change avec. Quand deux empreintes divergent sans explication, ce sont les deux premières choses à regarder, avant l’algorithme.

Une empreinte est un nombre ; minuscules et majuscules sont deux façons de l’écrire et tous les analyseurs acceptent les deux. Les minuscules sont la convention Unix et ce qu’imprime `md5sum`. Les majuscules apparaissent dans l’outillage Windows et dans beaucoup de documentation ancienne.

Le seul endroit où cela cesse d’être cosmétique est une comparaison faite sur des chaînes. Deux empreintes de la même valeur, une dans chaque casse, sont visiblement identiques et échouent à un test d’égalité — un bug qui traverse la relecture précisément parce que les deux valeurs se ressemblent à l’écran. Normalisez avant de comparer, ou comparez sans tenir compte de la casse.

On lit souvent qu’un hash est irréversible, ce qui est vrai au sens de l’arithmétique et trompeur au sens pratique. Personne ne défait le calcul ; on se contente de hacher des milliards de candidats et de comparer. Pour un mot de passe courant, une date de naissance, un numéro de téléphone ou une adresse électronique, la recherche est instantanée.

Il faut donc traiter le MD5 de toute valeur devinable comme public. C’est le point qui ruine l’idée d’« anonymiser » des adresses électroniques en les hachant : l’ensemble des adresses plausibles est petit, et le hash ne fait que le réécrire. Une donnée personnelle hachée reste une donnée personnelle, et le RGPD la traite comme telle.

Beaucoup de pages de téléchargement publient encore un MD5 à côté du fichier. Le vérifier a du sens contre un transfert interrompu ou un miroir défaillant : c’est exactement le cas accidentel où MD5 tient encore.

Cela n’a aucun sens contre quelqu’un qui aurait remplacé le fichier, puisqu’il peut fabriquer un fichier différent ayant la même empreinte. Si la page propose aussi un SHA-256, c’est celui-là qu’il faut prendre ; si elle ne propose que le MD5, la vérification vous dit que le téléchargement est complet et rien de plus.

Un MD5 fait toujours trente-deux caractères hexadécimaux, quelle que soit l’entrée. SHA-1 en fait quarante, SHA-256 soixante-quatre, SHA-512 cent vingt-huit. Compter les caractères d’une empreinte qu’on vous a donnée est le moyen le plus rapide de savoir de quel algorithme elle vient quand la documentation se tait.

C’est aussi un contrôle utile sur une colonne existante. Un champ censé contenir du SHA-256 qui contient trente-deux caractères contient du MD5, et il en contient parce que quelque chose en amont n’a jamais été mis à jour — un constat plus fréquent qu’il ne devrait l’être.