Le hachage expliqué : SHA-256, sommes de contrôle et mots de passe

Mis à jour : 14 octobre 2026

Une fonction de hachage transforme n’importe quelle entrée — un mot, un mot de passe, un fichier de 4 Go — en une courte empreinte de longueur fixe. La même entrée donne toujours la même empreinte, et la moindre modification en donne une complètement différente. C’est pourquoi le hachage est la méthode de référence pour vérifier qu’un fichier est arrivé intact, pour stocker des mots de passe sans conserver les mots de passe eux-mêmes et pour signer des messages. Ce guide explique ce qui rend une fonction de hachage sûre, quels algorithmes le sont encore, comment vérifier un téléchargement et pourquoi le hachage rapide qui convient à un fichier est le mauvais choix pour un mot de passe.

Ce que fait une fonction de hachage

Une fonction de hachage lit des données de n’importe quelle longueur et renvoie une empreinte (digest) de longueur fixe. SHA-256, la plus répandue aujourd’hui, renvoie toujours 256 bits, écrits sous la forme de 64 caractères hexadécimaux, que l’entrée soit une seule lettre ou l’image d’un disque entier.

c3c211099e2db0d1bb97343886c2b7e23981b636107a296a9fe642b99ca4cc1bSHA-256 de nTools.
420849368aee5e9b6838f98b4dde3f493de84c420baa785ea58a08acc2c0cfafSHA-256 de ntools : une seule lettre passée en minuscule, et une empreinte sans aucun rapport.

Toute fonction de hachage est déterministe — la même entrée donne la même empreinte sur n’importe quel ordinateur — et rapide à calculer. Une fonction de hachage cryptographique y ajoute les garanties décrites dans la section suivante, et ce sont elles qui permettent de l’utiliser pour la sécurité.

Une empreinte n’est pas une copie compressée : 64 caractères ne peuvent pas contenir un fichier de 4 Go. En théorie, de nombreuses entrées partagent chaque empreinte ; une fonction de hachage sûre fait simplement qu’il est impossible, en pratique, de les trouver.

Ouvrir le générateur de hachage

Ce qui rend une fonction de hachage sûre

La norme américaine qui définit SHA-256, FIPS 180-4, qualifie ces algorithmes de sûrs parce que certaines recherches sont irréalisables en temps de calcul. En pratique, cela recouvre trois propriétés :

Résistance aux préimages : à partir d’une empreinte, personne ne peut trouver une entrée qui la produit. C’est ce que signifie « à sens unique ».
Résistance aux secondes préimages : à partir d’un fichier, personne ne peut fabriquer un autre fichier ayant la même empreinte.
Résistance aux collisions : personne ne peut trouver deux entrées différentes, quelles qu’elles soient, ayant la même empreinte, même en choisissant librement les deux.

La résistance aux collisions est la première à céder, car l’attaquant contrôle les deux entrées. C’est ce qui est arrivé à MD5 et à SHA-1. Ce n’est pas un détail : les signatures numériques et les certificats sont calculés sur une empreinte du document, si bien que deux documents ayant la même empreinte partagent la même signature.

MD5, SHA-1, SHA-2 et SHA-3

Algorithme	Empreinte	Statut
`MD5`	128 bits, 32 caractères hexadécimaux	Cassé : les collisions sont réalisables en pratique. Le RFC 6151 (2011) l’exclut partout où la résistance aux collisions est requise, comme pour les signatures numériques.
`SHA-1`	160 bits, 40 caractères hexadécimaux	Cassé : première collision publique en 2017. Selon le NIST, il doit être abandonné progressivement d’ici le 31 décembre 2030.
`SHA-256`	256 bits, 64 caractères hexadécimaux	Sûr. Fait partie de la famille SHA-2 (FIPS 180-4) ; c’est le choix par défaut habituel aujourd’hui.
`SHA-384, SHA-512`	384 et 512 bits, 96 et 128 caractères hexadécimaux	Sûrs. Appartiennent aussi à SHA-2, avec une empreinte plus longue.
`SHA-3`	224 à 512 bits, selon la variante	Sûr. Normalisé en 2015 (FIPS 202) sur une conception différente, Keccak, pour compléter SHA-2 et non pour le remplacer.

La collision SHA-1, baptisée SHAttered, a été annoncée par Google et le CWI Amsterdam le 23 février 2017 : deux fichiers PDF différents ayant la même empreinte SHA-1, trouvés au prix d’environ 9,2 milliards de milliards de calculs SHA-1. Depuis, MD5 et SHA-1, employés comme simples fonctions de hachage, ne servent plus qu’à des vérifications rapides contre les dégradations accidentelles. La documentation de Microsoft sur la commande Windows de hachage de fichiers dit la même chose : ne les utiliser que pour une simple détection de modifications, jamais pour des fichiers qui doivent être protégés contre toute falsification.

Le générateur de hachage nTools propose SHA-256, SHA-384 et SHA-512. Il s’appuie sur l’API Web Crypto intégrée au navigateur, qui prend aussi en charge SHA-1 — en avertissant de ne pas l’utiliser à des fins cryptographiques — et ne propose pas du tout MD5.

Vérifier un téléchargement

Les éditeurs de logiciels indiquent souvent une somme de contrôle (checksum) à côté du fichier, généralement en SHA-256. Après le téléchargement, vous calculez l’empreinte de votre copie et vous comparez.

Notez l’algorithme utilisé par l’éditeur et copiez la somme de contrôle publiée.
Calculez l’empreinte du fichier téléchargé avec le même algorithme : dans le générateur de hachage nTools pour les fichiers jusqu’à 200 Mo, ou avec une commande comme celles ci-dessous, quelle que soit la taille.
Comparez chaque caractère, pas seulement les premiers et les derniers. En hexadécimal, majuscules et minuscules sont équivalentes.

Get-FileHash .\file.isoWindows PowerShell. SHA-256, sauf si vous ajoutez -Algorithm.
sha256sum file.isoLinux.
shasum -a 256 file.isomacOS.

Une correspondance prouve que le fichier est bien celui qui a été haché ; elle ne prouve pas qui l’a haché. Un attaquant capable de remplacer le fichier sur un site peut généralement remplacer aussi la somme de contrôle sur la même page. C’est pourquoi des projets comme Ubuntu signent également leur liste de sommes de contrôle : vous vérifiez d’abord la signature avec GPG, puis le fichier par rapport à la liste. Une fois l’empreinte de la clé de signature vérifiée sur le site du projet lui-même, le résultat reste valable même si vous avez téléchargé le fichier depuis un miroir non fiable.

Hachage, chiffrement et encodage

Méthode	Réversible ?	Clé ?	Usage
Hachage (par ex. SHA-256)	Non	Non	Vérifier l’intégrité, identifier des données, stocker des mots de passe avec un algorithme lent
Chiffrement (par ex. AES)	Oui, avec la clé	Oui	Garder des données secrètes
Encodage (par ex. Base64)	Oui, par n’importe qui	Non	Transporter des données binaires sous forme de texte, dans les e-mails, les URL et le JSON

Base64 et l’encodage d’URL ne protègent rien : ils changent la manière dont les données sont écrites, pas qui peut les lire. Les mots de passe chiffrés sont par ailleurs moins sûrs que les mots de passe hachés, avertit l’OWASP : le chiffrement est réversible, donc quiconque peut déchiffrer récupère les mots de passe d’origine. Il ne se justifie que dans les rares cas où l’original doit pouvoir être retrouvé.

Pourquoi un hachage rapide ne convient pas aux mots de passe

Un site ne devrait jamais stocker votre mot de passe, seulement son empreinte : à la connexion, il hache ce que vous tapez et compare le résultat. Le problème, c’est la vitesse. Une fonction de hachage qui vérifie un téléchargement de 4 Go en quelques secondes permet à quiconque vole la base de données de tester des milliards de candidats par seconde.

Algorithme	Tentatives par seconde, une RTX 4090	Temps pour essayer tous les mots de passe de 8 caractères (minuscules et chiffres)
MD5	164 milliards	17 secondes
SHA-1	51 milliards	56 secondes
SHA-256	22 milliards	2 minutes
SHA-512	7,5 milliards	6 minutes
PBKDF2-HMAC-SHA256, 600 000 itérations	environ 15 000	environ 6 ans
bcrypt, coût 10	environ 5 750	environ 15 ans

Vitesses tirées du benchmark hashcat 6.2.6 sur une seule carte graphique NVIDIA RTX 4090. Les deux dernières lignes sont extrapolées à partir des réglages propres au benchmark (999 itérations PBKDF2, bcrypt avec un coût de 5), car le temps croît proportionnellement au travail. La recherche couvre les 36⁸ candidats, soit environ 2 800 milliards. Les attaques réelles sont encore plus rapides : elles utilisent de nombreuses cartes à la fois et essaient d’abord les mots de passe les plus probables.

Le sel : même mot de passe, empreinte différente

Sans sel, toutes les personnes dont le mot de passe est 123456 ont la même empreinte stockée, et les attaquants conservent des tables contenant les empreintes de millions de mots de passe courants : les retrouver devient une simple consultation, et non une recherche.

8d969eef6ecad3c29a3a629280e686cf0c3f5d5a86aff3ca12020c923adc6c92SHA-256 de 123456, sans sel : identique dans toutes les bases de données qui le stockent de cette façon.

Un sel est une valeur aléatoire créée pour chaque mot de passe, stockée à côté de son empreinte et intégrée au calcul de celle-ci. Il n’est pas secret. Son rôle est de rendre chaque empreinte stockée unique : les tables précalculées deviennent inutiles, et chaque compte doit être attaqué séparément.

Le NIST SP 800-63B-4 exige que les mots de passe soient salés et hachés avec un schéma de hachage de mots de passe adapté et un sel d’au moins 32 bits, et recommande un facteur de coût aussi élevé que possible en pratique. Il recommande aussi une étape supplémentaire avec une clé secrète stockée à l’écart des empreintes, idéalement dans un module de sécurité matériel. L’OWASP appelle ce secret un « poivre » (pepper).

Que faut-il utiliser à la place ?

Les fonctions de hachage de mots de passe sont volontairement lentes, prennent le sel en entrée et disposent d’un paramètre de coût qu’il faut augmenter à mesure que le matériel gagne en rapidité. L’aide-mémoire de l’OWASP sur le stockage des mots de passe (Password Storage Cheat Sheet) fixe ces minimums :

Algorithme	Réglages minimaux	Quand l’utiliser
`Argon2id`	19 Mio de mémoire, 2 itérations, parallélisme 1	Premier choix. Chaque tentative exige de la mémoire, ce qui réduit l’avantage des cartes graphiques. Spécifié dans le RFC 9106 (2021).
`scrypt`	N = 2¹⁷, r = 8, p = 1	Si Argon2id n’est pas disponible. Exige aussi de la mémoire.
`bcrypt`	Coût 10 ou plus	Systèmes plus anciens. La plupart des implémentations acceptent au plus 72 octets de mot de passe ; au-delà, le mot de passe est tronqué ou refusé.
`PBKDF2-HMAC-SHA256`	600 000 itérations	Lorsque la conformité FIPS-140 est exigée.

Ce sont des minimums, conçus pour qu’une connexion ne prenne qu’une fraction de seconde sur le serveur tout en rendant chaque tentative coûteuse. Vous ne pouvez pas savoir lequel un site utilise : c’est pourquoi les conseils du guide sur les mots de passe — longs, aléatoires et jamais réutilisés — partent du pire des cas.

HMAC : un hachage avec une clé

Une empreinte simple montre que des données n’ont pas changé, mais n’importe qui peut la calculer : celui qui modifie les données peut tout simplement recalculer l’empreinte. HMAC, défini dans le RFC 2104 en 1997, intègre une clé secrète au hachage, de sorte que seule une personne possédant la clé peut produire ou vérifier le résultat.

C’est ainsi que les API signent leurs requêtes, que les webhooks prouvent qu’ils viennent bien de l’expéditeur, et que de nombreux JSON Web Tokens sont signés : l’algorithme JWT HS256 n’est autre que HMAC avec SHA-256.

Questions fréquentes

Peut-on inverser une empreinte ?

Non. L’empreinte ne contient pas l’entrée : il n’y a donc rien à décoder. Ce que font les attaquants, c’est deviner : ils hachent des candidats jusqu’à ce que l’un d’eux corresponde. Cela fonctionne pour des entrées courtes ou courantes, comme les mots de passe, et échoue pour des entrées longues et aléatoires.

MD5 sert-il encore à quelque chose ?

Pour repérer des modifications accidentelles, comme une copie corrompue ou un fichier en double, oui. Pas là où quelqu’un pourrait falsifier les données délibérément, et jamais pour des mots de passe ou des signatures.

Deux fichiers peuvent-ils avoir la même empreinte SHA-256 ?

En théorie, oui : il existe plus de fichiers possibles que d’empreintes. En pratique, aucune collision n’a jamais été trouvée pour SHA-256 complet, et une recherche par force brute demanderait de l’ordre de 2¹²⁸ tentatives.

Une empreinte plus longue est-elle toujours plus sûre ?

Jusqu’à un certain point seulement. Avec 256 bits, une recherche de collision est déjà largement hors de portée ; la solidité de l’algorithme compte davantage, comme l’a montré SHA-1. SHA-384 et SHA-512 sont utilisés lorsqu’une règle les impose ou pour disposer d’une marge supplémentaire.

Mon fichier est-il envoyé en ligne quand je le hache sur nTools ?

Non. Le fichier est lu et haché dans votre navigateur, et seule l’empreinte est affichée.

Partie précédente ← La robustesse des mots de passe expliquée : longueur, entropie et phrases de passe