MD5, SHA-1, SHA-256 : quel hachage, et pour quoi faire

Trois propriétés, pas une

Presque toute discussion sur les fonctions de hachage déraille dès la première phrase, parce que le mot « sûr » recouvre trois garanties différentes. La résistance à la préimage dit qu'à partir d'une seule empreinte, tu ne peux pas remonter à une entrée qui la produit. La résistance à la seconde préimage dit qu'à partir d'une entrée donnée — ce contrat, ce binaire — tu ne peux pas en trouver une autre de même empreinte. La résistance aux collisions dit quelque chose de plus fort et de plus étrange : tu ne peux trouver aucune paire d'entrées en collision, même en choisissant les deux, même si aucune ne veut rien dire.

Les trois se classent par difficulté pour l'attaquant, et le paradoxe des anniversaires explique pourquoi. Trouver une préimage d'une empreinte de n bits coûte environ 2^n opérations ; trouver une collision n'en coûte qu'environ 2^(n/2), parce que tu ne vises pas une cible : tu attends que deux de tes candidats coïncident. Pour SHA-256, cela fait 2^256 contre 2^128 — les deux hors d'atteinte. Pour MD5, 2^128 contre 2^64 générique, et la cryptanalyse a fait descendre le chiffre réel bien en dessous. La résistance aux collisions est donc toujours la première à tomber, et elle tombe très longtemps avant la résistance à la préimage.

Ce qui a réellement été « cassé »

MD5 est tombé le premier. Xiaoyun Wang et ses co-auteurs ont publié des collisions pratiques en 2004, et en quelques années la technique s'est raffinée en collisions à préfixe choisi, où l'attaquant contrôle le début des deux messages en collision et peut donc faire de chacun un document sensé. C'est ce qui rend possible la falsification de signature : tu fais signer par un tiers de confiance la moitié inoffensive d'une paire en collision, puis tu attaches sa signature à l'autre moitié. Aujourd'hui, une collision MD5 simple prend quelques secondes sur du matériel ordinaire.

SHA-1 a tenu jusqu'en février 2017, quand le CWI d'Amsterdam et Google Research ont publié SHAttered : deux fichiers PDF visiblement différents, de même empreinte SHA-1. Leur annonce chiffre le coût à 9 223 372 036 854 775 808 calculs SHA-1. Ce nombre n'a rien d'arbitraire : c'est exactement 2^63, confortablement sous les 2^80 qu'exigerait une attaque des anniversaires générique sur une empreinte de 160 bits. Trois ans plus tard, Leurent et Peyrin ont étendu le résultat aux collisions à préfixe choisi ; SHA-1 était dès lors terminé pour tout usage adverse, et les autorités de certification et systèmes de gestion de versions qui l'émettaient encore ont entamé la longue migration.

Note ce qu'aucun de ces résultats ne donne à l'attaquant. Personne ne peut prendre une empreinte MD5 que tu publies et en retrouver l'entrée. Personne ne peut prendre un fichier existant et fabriquer un second fichier de même MD5. Les deux attaques exigent que l'adversaire construise les deux moitiés dès le départ. C'est exactement la frontière entre une somme de contrôle qui repère un téléchargement corrompu — la corruption n'a rien choisi — et une signature qui doit survivre à quelqu'un qui construit délibérément les deux documents.

Les empreintes, côte à côte

Passe la chaîne « hello » dans chaque algorithme et les différences sautent aux yeux. MD5 donne 5d41402abc4b2a76b9719d911017c592, trente-deux caractères hexadécimaux pour 128 bits. SHA-1 donne aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d, quarante caractères pour 160 bits. SHA-256 donne 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824, soixante-quatre caractères pour 256 bits. Chaque caractère hexadécimal porte quatre bits : la longueur en caractères vaut toujours la longueur en bits divisée par quatre — un moyen rapide d'identifier un hachage non étiqueté dans un journal ou une colonne de base de données.

Ajoute maintenant un simple point. sha256("hello.") vaut 1589999b0ca6ef8814283026a9f166d51c70a910671c3d44049755f07f2eb910 — pas un caractère en commun avec l'empreinte de "hello" à une position prévisible. C'est l'effet avalanche, et il tient tout aussi fortement dans MD5, dont l'empreinte de "hello." est d94c10e437d18531e122ed0b45badd2a. Ce n'est pas l'avalanche qui a lâché. MD5 brasse toujours magnifiquement ; simplement, un attaquant assez habile sait diriger deux brassages vers le même point.

Une falsification reproductible : l'extension de longueur

MD5, SHA-1, SHA-256 et SHA-512 partagent tous la construction de Merkle-Damgard : le message est complété, découpé en blocs fixes, et chaque bloc met à jour un état interne courant. L'empreinte que tu publies est cet état interne. Autrement dit, quiconque détient ton empreinte peut la recharger dans l'algorithme et continuer à hacher, comme s'il avait été là depuis le début. C'est la propriété d'extension de longueur, et ce n'est un bug dans aucune de ces fonctions — c'est ce que fait la construction.

La voici exécutée. Prends une étiquette d'authentification naïve construite comme sha256(secret + message), avec un secret de 32 octets et le message user=alice&role=viewer. L'étiquette légitime commence par 0556f5e825e91626. Un attaquant qui ne connaît que le message, l'étiquette et la longueur du secret — pas le secret lui-même — peut reprendre SHA-256 à partir de cette étiquette, ajouter les dix octets de remplissage 800000000000000001b0 que le hachage d'origine aurait insérés, puis ajouter &role=admin. L'étiquette obtenue est cca75089ae751c4359a577329d74d9ba345ed7e5f83f988583b2baa16cad5efe, et c'est octet pour octet l'empreinte que le serveur calcule sur le message étendu. La falsification passe la vérification. Le secret n'a jamais été connu.

Le correctif n'est ni une empreinte plus longue ni une autre variante de SHA-2. C'est HMAC, qui imbrique le hachage deux fois avec deux clés dérivées, de sorte que l'étiquette publiée n'est plus un état interne reprenable. HMAC-SHA-256 sur la même clé et le même message donne 2ad69479d608c0fc4c89387db138aebb0bbee3b35d46057726228cacfc8a1478, et aucun ajout ne t'en donnera une extension valide. SHA-3 est immunisé pour une autre raison : sa construction en éponge ne sort qu'une partie de l'état interne, si bien que l'empreinte ne dit pas où l'algorithme en était.

Aucun de ces algorithmes n'est un hachage de mot de passe

C'est l'erreur la plus coûteuse, et elle n'a rien à voir avec les collisions. Les hachages généralistes sont conçus pour le débit, et ils le tiennent. Mesuré sur un seul cœur avec un tampon de 64 Mo, MD5 tourne à 632 Mo/s, SHA-256 à 1 075 Mo/s et SHA-1 à 1 357 Mo/s. L'ordre mérite un second regard : SHA-256 est ici 70 % plus rapide que MD5, parce que les processeurs modernes embarquent des instructions SHA dédiées et aucune instruction MD5. « MD5 est plus rapide » a cessé d'être fiable il y a des années.

La vitesse est précisément la mauvaise propriété pour un mot de passe stocké, parce que l'attaquant qui détient ta base en profite bien plus que toi. Tu haches un mot de passe par connexion ; lui en hache des milliards par seconde sur une baie de GPU. Les fonctions de hachage de mots de passe inversent délibérément ce marché. Sur la même machine, PBKDF2-SHA-256 à 600 000 itérations prend 148 millisecondes par mot de passe, et scrypt avec N = 131 072 en prend 397. Cela fait environ sept mots de passe par seconde au lieu de millions — un handicap volontaire que tu paies une fois par connexion et l'attaquant une fois par essai.

La bonne réponse à « quel hachage pour les mots de passe » est donc : aucun de ceux de cet article. Utilise Argon2id quand tu choisis librement, bcrypt quand la plateforme ne t'offre rien d'autre, scrypt ou PBKDF2 quand une norme les impose, toujours avec un sel aléatoire unique par utilisateur. SHA-256 garde sa place à l'intérieur de ces constructions — PBKDF2-SHA-256 est bâti dessus — mais il est la primitive, pas le schéma.

SHA-3 n'est pas un SHA-2 en plus gros

La numérotation induit en erreur. SHA-2 a succédé à SHA-1 comme conception améliorée dans la même lignée ; SHA-3 n'a pas du tout succédé à SHA-2 en ce sens. Il est issu d'un concours ouvert lancé par le NIST en 2007, remporté par l'équipe Keccak, et normalisé dans FIPS 202 en 2015 — alors que SHA-2 se portait parfaitement bien, et se porte toujours bien. Le NIST n'a jamais demandé à quiconque d'abandonner SHA-2.

L'intérêt de SHA-3 est la diversité architecturale. Comme c'est une éponge et non une chaîne de Merkle-Damgard, une attaque qui casserait SHA-2 ne l'atteindrait très probablement pas, et le monde disposerait d'un remplaçant prêt à l'emploi. L'éponge supprime aussi gratuitement l'extension de longueur, ce pour quoi certaines conceptions le préfèrent déjà. Son coût est la vitesse : SHA3-256 mesure 317 Mo/s sur le matériel même où SHA-256 atteint 1 075 Mo/s, largement parce que le matériel accélère l'un et pas l'autre. Choisis SHA-3 quand tu veux la construction différente, pas quand tu veux plus de bits — SHA3-256 et SHA-256 offrent les mêmes 256.

Une courte liste de décision

Signer quoi que ce soit, vérifier un téléchargement venu d'un réseau hostile, bâtir un arbre de Merkle, dériver une adresse de contenu : SHA-256. Stocker un mot de passe ou en dériver une clé : Argon2id, bcrypt ou scrypt, jamais un hachage nu. Authentifier un message avec un secret partagé : HMAC-SHA-256, pas sha256(secret + message), pour la raison démontrée plus haut. Dédupliquer des fichiers, indexer un cache, répartir une table de hachage, repérer un transfert tronqué : MD5 convient toujours et reste assez rapide, à condition que personne dans le tableau n'ait intérêt à une collision.

Un seul test tranche les cas douteux. Demande-toi si quelqu'un qui a intérêt à ce que deux entrées partagent une empreinte peut aussi choisir ces entrées. Si la réponse est non — un défaut de disque, un câble capricieux, un téléversement partiel — une résistance aux collisions cassée ne te coûte rien. Si la réponse est oui, ou risque de le devenir dès que la donnée quitte ta machine, il te faut un hachage dont la résistance aux collisions est intacte : SHA-256 ou mieux.

Questions fréquentes

MD5 est-il sûr en 2026 ?

Uniquement là où aucun adversaire n'a intérêt à une collision. MD5 a perdu la résistance aux collisions en 2004 et une collision prend désormais quelques secondes : tout usage où quelqu'un gagnerait à faire partager une empreinte à deux entrées différentes — signatures, certificats, contrôles d'intégrité sur un réseau non fiable, déduplication de fichiers fournis par l'attaquant — est dangereux. Les usages dont la seule menace est l'accident restent valables : vérifier qu'une copie n'a pas été tronquée, indexer un cache, répartir des données entre serveurs, comparer des sauvegardes locales. MD5 n'a pas perdu la résistance à la préimage : une empreinte publiée ne révèle pas non plus son entrée. La règle pragmatique : MD5 est une empreinte rapide, pas un contrôle de sécurité. Ce n'est d'ailleurs même plus l'option la plus rapide : mesuré sur un cœur, SHA-256 tourne à 1 075 Mo/s contre 632 Mo/s pour MD5, car les processeurs embarquent des instructions SHA. Si la vitesse était ta raison, elle a expiré.

Peut-on déchiffrer ou inverser un hachage SHA-256 ?

Non, et le mot déchiffrer ne s'applique pas — le hachage n'est pas du chiffrement : il n'y a ni clé ni chemin de retour prévu. SHA-256 envoie des entrées de longueur quelconque sur 256 bits ; une infinité d'entrées partagent donc chaque empreinte et l'originale ne peut être isolée, même en principe. Retrouver une entrée signifie force brute : deviner des candidats et hacher chacun jusqu'à correspondance. C'est pourquoi les sites dits de « cassage de hachage » fonctionnent. Ils n'inversent rien ; ils détiennent des tables précalculées d'empreintes d'entrées courantes et cherchent la vôtre. Face à une valeur aléatoire de 32 octets, la recherche échoue et 2^256 essais subsistent. Face à la chaîne « password », elle réussit instantanément. Conséquence pratique : l'empreinte d'un secret à faible entropie n'est presque plus un secret, ce qui est exactement la raison pour laquelle le stockage de mots de passe ajoute un sel par utilisateur (contre les tables partagées) et une fonction délibérément lente (contre la devinette rapide).

Faut-il utiliser SHA-512 plutôt que SHA-256 pour plus de sécurité ?

Rarement rentable. SHA-256 offre 128 bits de résistance aux collisions et 256 de résistance à la préimage ; SHA-512 double les deux, à 256 et 512. Comme aucune attaque contre SHA-256 n'approche 2^128, la marge supplémentaire n'achète rien d'identifiable, tandis que l'empreinte double à 128 caractères hexadécimaux dans chaque colonne, chaque URL et chaque ligne de journal qui doit la porter. Deux raisons réelles de choisir SHA-512. La performance en logiciel 64 bits sans accélération SHA matérielle, où les mots de 64 bits de SHA-512 peuvent devancer SHA-256 — bien que sur du matériel qui accélère SHA-256, l'ordre s'inverse, comme ici, 1 075 Mo/s contre 516 Mo/s. Et une spécification qui l'exige. SHA-512/256, variante tronquée définie dans FIPS 180-4, offre la vitesse des mots de 64 bits avec une sortie de 256 bits : le compromis le plus propre quand il te faut les deux.

Pourquoi ne pas simplement hacher les mots de passe en SHA-256 avec un sel ?

Un sel règle un problème et laisse le plus gros intact. Il neutralise les tables précalculées et force l'attaquant à traiter chaque compte séparément — ce qui a une vraie valeur. Ce qu'il ne change pas, c'est le coût par essai. SHA-256 est conçu pour être bon marché, et un attaquant disposant de ta base salée attaque chaque compte au rythme que son matériel permet, ce qui, sur une baie de GPU, est colossal. La défense doit rendre chaque essai coûteux : c'est le travail d'une fonction de hachage de mots de passe. Mesuré ici, PBKDF2-SHA-256 à 600 000 itérations coûte 148 ms par mot de passe et scrypt à N = 131 072 coûte 397 ms ; Argon2id ajoute par-dessus un coût mémoire, de sorte qu'un GPU ne peut pas simplement exécuter des milliers d'instances en parallèle. Sel et lenteur sont tous deux nécessaires, et seule la seconde dépend de l'algorithme choisi. Utilise Argon2id, bcrypt ou scrypt, et laisse SHA-256 à sa place, à l'intérieur.

Qu'est-ce que l'extension de longueur, et suis-je concerné ?

Elle ne te concerne que si tu as construit une étiquette d'authentification comme hash(secret + message). Comme MD5, SHA-1 et la famille SHA-2 publient leur état interne en guise d'empreinte, quiconque détient cette empreinte peut reprendre le calcul et produire une étiquette valide pour le message augmenté de données ajoutées, sans jamais apprendre le secret. Ce n'est pas théorique : en partant d'une vraie étiquette sur un secret de 32 octets et user=alice&role=viewer, en ajoutant les dix octets de remplissage 800000000000000001b0 puis &role=admin, on obtient cca75089ae751c4359a577329d74d9ba345ed7e5f83f988583b2baa16cad5efe, exactement ce que calcule le serveur. Comme les analyseurs de requête retiennent souvent la dernière occurrence d'une clé répétée, cette extension bascule le rôle. Deux correctifs : utiliser HMAC, conçu pour l'authentification à clé et non extensible, ou SHA-3, dont l'éponge n'expose jamais l'état complet. Si tu haches simplement un fichier sans secret, l'extension de longueur ne te fait rien.

Dois-je migrer de SHA-2 vers SHA-3 ?

Non. Le NIST a normalisé SHA-3 dans FIPS 202 comme une alternative, pas un remplacement, et continue d'approuver la famille SHA-2 dans FIPS 180-4, sans obsolescence en vue. SHA-3 existe parce que dépendre d'une seule construction est un risque systémique : SHA-1 et SHA-2 partagent une lignée de conception, si bien qu'une percée contre l'un a légitimement inquiété pour l'autre. L'éponge de Keccak est un mécanisme entièrement différent, et c'est tout l'intérêt. Choisis SHA-3 dans trois situations. Quand un protocole ou un régulateur l'impose. Quand tu veux l'immunité à l'extension de longueur sans tout envelopper dans HMAC. Quand tu conçois quelque chose destiné à survivre au consensus cryptographique actuel et veux de la diversité de construction. Sinon, SHA-256 reste le défaut sensé, et il est généralement plus rapide parce que les processeurs l'accélèrent : ici 1 075 Mo/s contre 317 Mo/s pour SHA3-256. Note aussi que le niveau de sécurité est identique — SHA3-256 et SHA-256 donnent des empreintes de 256 bits et 128 bits de résistance aux collisions.