MD5 vs SHA-256 vs SHA-512 — Fonctions de hachage expliquées

Les fonctions de hachage sont omniprésentes dans le développement logiciel : vérification d'intégrité de fichiers, stockage de mots de passe, signatures numériques, authentification d'API, clés de cache, déduplication. Pourtant, la plupart des développeurs les utilisent comme des boîtes noires — vous fournissez une chaîne, vous obtenez en retour un condensé hexadécimal de longueur fixe. Les détails sur quelle fonction de hachage utiliser, et laquelle éviter, s'avèrent très importants.

MD5 est compromis. SHA-1 est déprécié. SHA-256 et SHA-512 sont actuellement sûrs. SHA-3 existe si vous voulez une protection à long terme. Mais « compromis » ne signifie pas la même chose dans tous les contextes — MD5 convient à certains cas d'usage et est désastreux pour d'autres. Ce guide explique les propriétés qui comptent, comment chaque fonction y répond, et vous propose un cadre de décision clair pour choisir le bon hachage en 2026.

Ce que fait réellement une fonction de hachage

Une fonction de hachage cryptographique transforme une entrée de longueur arbitraire en une sortie de longueur fixe (le condensé ou hachage). Trois propriétés définissent une fonction de hachage cryptographiquement sûre :

• Résistance à la préimage — étant donné un hachage h, il doit être computationnellement infaisable de trouver une entrée m telle que hash(m) = h. C'est la propriété « sens unique ».
• Résistance à la seconde préimage — étant donné une entrée m1, il doit être infaisable de trouver une entrée différente m2 telle que hash(m1) = hash(m2).
• Résistance aux collisions — il doit être infaisable de trouver deux entrées distinctes quelconques m1 et m2 telles que hash(m1) = hash(m2).

Une fonction qui ne satisfait pas l'une de ces propriétés est considérée comme compromise pour un usage cryptographique. Notez qu'« infaisable » a une signification précise ici : cela ne veut pas dire mathématiquement impossible, mais nécessitant plus de calcul que ce qui est pratique avec le matériel actuel ou prévisible.

De plus, les fonctions de hachage cryptographiques présentent l'effet avalanche : modifier un seul bit de l'entrée produit une sortie qui diffère dans environ la moitié de ses bits. Cela garantit que des entrées similaires produisent des condensés complètement différents.

Input:  "hello"
MD5:    5d41402abc4b2a76b9719d911017c592  (128 bits / 32 caractères hex)

Input:  "Hello"
MD5:    8b1a9953c4611296a827abf8c47804d7  (un seul changement de caractère = sortie complètement différente)

MD5 — Rapide, omniprésent et compromis

Histoire et conception

MD5 (Message Digest 5) a été conçu par Ron Rivest en 1991 et produit un condensé de 128 bits (16 octets). Pendant la majeure partie des années 1990, c'était le choix standard pour la vérification d'intégrité des fichiers, la signature de certificats et le hachage de mots de passe. Il est extrêmement rapide — un CPU moderne peut calculer des dizaines de millions de hachages MD5 par seconde, et un GPU peut en calculer des milliards.

Pourquoi MD5 est compromis

En 2004, Xiaoyun Wang et ses collègues ont démontré une attaque par collision pratique contre MD5 — deux fichiers différents produisant le même hachage MD5. L'attaque s'exécute en quelques minutes sur du matériel grand public. En 2008, des chercheurs ont créé un faux certificat d'autorité de certification en utilisant une collision MD5, démontrant que l'infrastructure PKI réelle était vulnérable. En 2012, le malware Flame a utilisé une collision MD5 pour falsifier un certificat de signature de code Microsoft.

Le NIST a officiellement déprécié MD5 pour la plupart des usages cryptographiques. Les autorités de certification ont cessé d'émettre des certificats signés avec MD5 en 2009. Les éditeurs de navigateurs ont supprimé le support des signatures de certificats MD5 vers 2011.

Quand MD5 reste acceptable

MD5 n'est pas universellement inutile. Pour des sommes de contrôle non liées à la sécurité — détecter une corruption accidentelle de données lors de transferts de fichiers, l'adressage basé sur le contenu dans un système de cache où l'attaquant ne peut pas influencer les entrées, ou générer des identifiants uniques dans un système interne fermé — MD5 reste adéquat. Le test clé : si un attaquant peut bénéficier de la création d'une collision, n'utilisez pas MD5. Si seule la corruption accidentelle importe, MD5 convient.

• Sûr : déduplication interne, clés de cache, détection de changement de fichier non liée à la sécurité
• Non sûr : certificats, signatures numériques, hachage de mots de passe, vérification d'authenticité de fichiers, jetons de sécurité

SHA-1 — Déprécié mais pas disparu

SHA-1 produit un condensé de 160 bits et était le successeur de MD5. Il est resté le standard pour la signature de certificats et la signature de code pendant la majeure partie des années 2000. En 2017, l'attaque SHAttered a démontré la première collision SHA-1 pratique, produisant deux fichiers PDF différents avec des hachages SHA-1 identiques en utilisant environ 110 années-GPU de calcul — coûteux mais à la portée d'États et de plus en plus accessible.

SHA-1 est déprécié par le NIST et toutes les principales autorités de certification. Il ne doit pas être utilisé pour des certificats, la signature de code ou toute nouvelle application sensible à la sécurité. Certains systèmes hérités utilisent encore SHA-1 en interne, mais la migration vers SHA-256 est fortement recommandée. Git utilise encore SHA-1 pour l'adressage des objets (bien que la transition vers SHA-256 soit en cours), mais cela est en train d'être abandonné.

SHA-256 — Le standard actuel

SHA-256 fait partie de la famille SHA-2, conçue par la NSA et standardisée par le NIST dans FIPS 180-4. Il produit un condensé de 256 bits (32 octets). SHA-256 a été analysé de manière intensive depuis sa publication en 2001 et aucune attaque pratique n'a été trouvée. C'est la norme de facto pour :

• Les certificats TLS (pratiquement tous les certificats émis aujourd'hui utilisent SHA-256)
• La signature de code (Windows Authenticode, notarisation Apple, JARs)
• HMAC-SHA256 pour l'authentification d'API (AWS Signature v4, vérification de webhook GitHub)
• Les signatures de jetons JWT (HS256 et RS256 utilisent tous deux SHA-256 en interne)
• Les ID de transaction blockchain (Bitcoin utilise double-SHA256)
• La vérification d'intégrité des fichiers dans les gestionnaires de paquets (npm, pip, apt)

Input:  "hello"
SHA-256: 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
         (256 bits / 64 caractères hex)

SHA-512: 9b71d224bd62f3785d96d46ad3ea3d73319bfbc2890caadae2dff72519673ca72323c3d
         99ba5c11d7c7acc6e14b8c5da0c4663475c2e5c3adef46f73bcdec043
         (512 bits / 128 caractères hex)

Performances de SHA-256

SHA-256 utilise des opérations sur des mots de 32 bits en interne. Sur du matériel 32 bits ou des CPU plus anciens sans accélération matérielle, il est notablement plus lent que MD5. Sur les CPU 64 bits modernes avec extensions SHA (Intel Goldmont+, AMD Zen+, Apple Silicon, ARM Cortex-A57+), SHA-256 est accéléré matériellement et extrêmement rapide — approchant souvent les vitesses de MD5. La plupart des environnements serveur disposent de l'accélération matérielle, donc en pratique SHA-256 est suffisamment rapide pour pratiquement toutes les applications.

SHA-512 — Plus large, parfois plus rapide

SHA-512 produit un condensé de 512 bits (64 octets) en utilisant des opérations sur des mots de 64 bits en interne. Sur du matériel 64 bits sans extensions SHA, SHA-512 peut en réalité être plus rapide que SHA-256 car ses opérations 64 bits font un meilleur usage des largeurs de registres modernes. Sur du matériel avec extensions SHA, SHA-256 est généralement plus rapide car les extensions sont spécifiquement optimisées pour SHA-256.

SHA-512 offre une marge de sécurité plus grande — 256 bits de résistance aux collisions contre 128 bits pour SHA-256. Pour la plupart des modèles de menace actuels, la résistance aux collisions de 128 bits de SHA-256 est plus que suffisante (la briser nécessiterait environ 2^128 opérations). SHA-512 est approprié lorsque :

• Vous ciblez des serveurs 64 bits et souhaitez un débit maximal sans extensions matérielles
• Vous avez besoin de condensés plus longs comme matériau de clé pour d'autres opérations cryptographiques
• Vous souhaitez une marge de sécurité supplémentaire pour des données devant rester protégées pendant des décennies
• Vous implémentez des protocoles qui requièrent spécifiquement SHA-512 (par ex. certaines suites de chiffrement TLS)

SHA-384 et SHA-512/256

SHA-384 est une version tronquée de SHA-512 produisant 384 bits — utile lorsque vous souhaitez les opérations internes 64 bits de SHA-512 mais avez besoin d'une sortie plus courte. SHA-512/256 est une autre variante tronquée qui produit une sortie de 256 bits en utilisant le calcul interne de SHA-512. SHA-512/256 est résistant aux attaques par extension de longueur qui affectent SHA-256, ce qui le rend utile dans les contextes où l'extension de longueur est une préoccupation (bien que HMAC atténue déjà cela dans la plupart des scénarios pratiques).

SHA-3 — Architecture différente, à l'épreuve du futur

SHA-3 (standardisé dans NIST FIPS 202, 2015) utilise la construction éponge Keccak — une conception fondamentalement différente de la structure Merkle-Damgård de SHA-2. C'est important car toute faiblesse future découverte dans la conception Merkle-Damgård affecterait MD5, SHA-1 et SHA-2 simultanément, tandis que SHA-3 resterait inaffecté.

SHA-3 est actuellement sûr et constitue le bon choix pour les nouveaux systèmes nécessitant une assurance à long terme ou souhaitant se prémunir contre de futures faiblesses de SHA-2. Il est plus lent que SHA-256 dans les implémentations logicielles pures. SHA-3 brille dans les implémentations matérielles — sa conception est très efficace en silicium. SHA-3-256 et SHA-3-512 produisent les mêmes tailles de condensé que leurs homologues SHA-2.

Tableau comparatif

Hachage de mots de passe : un problème entièrement différent

Cette section mérite d'être traitée séparément car c'est l'une des erreurs les plus courantes des développeurs. SHA-256 est le bon outil pour les vérifications d'intégrité de fichiers, la signature d'API et la vérification de certificats. C'est le mauvais outil pour hacher des mots de passe, et son utilisation à cette fin provoque de véritables incidents de sécurité.

Le problème, c'est la vitesse. SHA-256 est conçu pour être rapide — un GPU moderne peut calculer des milliards de hachages SHA-256 par seconde. Un attaquant qui obtient votre base de données de mots de passe hachés peut tenter des milliards de devinettes par seconde. Même un mot de passe long et aléatoire peut être craqué rapidement si le hachage est rapide.

// NE JAMAIS faire cela pour les mots de passe
const hash = crypto.createHash('sha256').update(password).digest('hex');

// Utilisez bcrypt, scrypt ou Argon2 pour les mots de passe
const bcrypt = require('bcrypt');
const hash = await bcrypt.hash(password, 12);  // facteur de coût 12

L'outil Test Bcrypt vous permet de hacher et vérifier des mots de passe bcrypt dans le navigateur. Pour comprendre les facteurs de coût bcrypt et leur temps de calcul, c'est une référence utile lors de la configuration du facteur de travail de votre application.

HMAC : ajouter l'authentification à un hachage

Un hachage simple ne prouve rien sur son auteur — n'importe qui ayant accès aux données peut calculer le même hachage SHA-256. HMAC (Code d'authentification de message basé sur un hachage) ajoute une clé secrète au calcul, produisant un tag qui ne peut être reproduit que par quelqu'un connaissant la clé. HMAC-SHA256 est la norme pour :

• La vérification des signatures de webhook (GitHub, Stripe, Shopify utilisent tous HMAC-SHA256)
• AWS Signature Version 4 (signature de requêtes)
• Les jetons JWT HS256 (HMAC-SHA256 de l'en-tête + charge utile)
• L'intégrité des cookies (signature des cookies de session pour prévenir la falsification)

const crypto = require('crypto');

// Signer un message avec HMAC-SHA256
const mac = crypto
  .createHmac('sha256', secretKey)
  .update(message)
  .digest('hex');

// Vérifier : comparer en temps constant (prévient les attaques temporelles)
const isValid = crypto.timingSafeEqual(
  Buffer.from(mac, 'hex'),
  Buffer.from(received, 'hex')
);

Notez l'utilisation de timingSafeEqual pour la comparaison. Comparer des valeurs MAC avec une vérification d'égalité de chaîne ordinaire divulgue des informations de timing qui peuvent être exploitées dans une attaque temporelle. Utilisez toujours une fonction de comparaison en temps constant lors de la vérification des MACs. Utilisez le Générateur HMAC pour calculer des valeurs HMAC-SHA256 lors des tests et du débogage sans écrire de code.

Recommandations pratiques

Intégrité générale de fichiers (sommes de contrôle)

Utilisez SHA-256. C'est la norme pour la vérification de paquets (fichiers lockfile npm, hachages de requirements pip, couches d'images Docker). L'outil Hachage SHA-256 calcule des condensés SHA-256 dans votre navigateur pour des entrées texte ou des valeurs de chaîne. Pour des sommes de contrôle rapides non liées à la sécurité où la vitesse est critique et que vous faites confiance à la source, MD5 reste acceptable, mais SHA-256 est préférable dans tout contexte partagé ou automatisé.

Certificats TLS et signature de code

SHA-256 est le standard requis. Toutes les autorités de certification émettent des certificats SHA-256. N'utilisez jamais MD5 ou SHA-1 pour de nouveaux certificats — ils seront rejetés par les navigateurs et systèmes d'exploitation modernes.

Authentification d'API

Utilisez HMAC-SHA256. C'est la norme établie, bien supportée dans tous les langages, et l'algorithme attendu par la plupart de la documentation de sécurité des API. Calculez des condensés avec l'outil Hachage MD5 ou Hachage SHA-256 pour des comparaisons rapides, et générez des signatures HMAC avec le Générateur HMAC.

Hachage de mots de passe

Utilisez bcrypt (facteur de coût 12+), scrypt ou Argon2id. N'utilisez jamais directement MD5, SHA-1, SHA-256 ou SHA-512 pour des mots de passe, même avec un sel. L'outil Test Bcrypt peut vous aider à vérifier des hachages bcrypt pendant le développement.

Données à longue durée de vie nécessitant des décennies de sécurité

Préférez SHA-512 ou SHA-3-256. La taille de condensé plus grande offre une marge supplémentaire contre les avancées en cryptanalyse. Le NIST recommande SHA-512 et SHA-3 pour les applications nécessitant une sécurité à long terme. Consultez les directives officielles dans NIST FIPS 180-4 pour la spécification faisant autorité des algorithmes SHA-2.

Nouveaux systèmes sans contraintes héritées

SHA-256 pour un usage général. Argon2id pour les mots de passe. HMAC-SHA256 pour les codes d'authentification. Si vous souhaitez une protection à long terme et pouvez accepter des performances légèrement inférieures, SHA-3-256 est une solide alternative à SHA-256 pour le hachage à usage général.