Le hachage est le processus de conversion d’une valeur donnée en une autre valeur. Une fonction de hachage est utilisée pour générer la nouvelle valeur selon un algorithme mathématique. Le résultat d’une fonction de hachage est connu sous le nom de valeur de hachage ou, simplement, un haché.
Les bonnes fonctions de hachage utilisent généralement un algorithme de hachage unidirectionnel : autrement dit, le haché ne peut pas être reconverti en la valeur d’origine.
Ce que produit une fonction de hachage
Une fonction de hachage accepte en entrée une donnée de taille quelconque — un mot, un mot de passe, un fichier de plusieurs gigaoctets — et produit en sortie une suite de bits de longueur fixe. Cette sortie porte plusieurs noms selon les documents : haché, empreinte, condensat, ou digest en anglais. Sa longueur dépend de l’algorithme choisi, jamais de la taille de l’entrée.
SHA-256 (Secure Hash Algorithm, variante produisant 256 bits) produit toujours 256 bits, soit 32 octets. Ces 32 octets sont presque toujours affichés en hexadécimal, une notation qui représente chaque octet par deux caractères pris parmi 0 à 9 et a à f. Une empreinte SHA-256 se présente donc comme une chaîne de 64 caractères.
$ printf 'bonjour' | sha256sum
2cb4b1431b84ec15d35ed83bb927e27e8967d75f4bcd9cc4b25c8d879ae23e18 -
$ printf 'Bonjour' | sha256sum
9172e8eec99f144f72eca9a568759580edadb2cfd154857f07e657569493bc44 -Ces deux commandes se reproduisent telles quelles sur tout système Linux disposant de la commande sha256sum, ce qui est le cas des distributions courantes. La commande printf est employée plutôt que echo parce qu’elle n’ajoute pas de retour à la ligne : ce caractère supplémentaire ferait partie de la donnée hachée et changerait entièrement le résultat. Le tiret en fin de sortie indique que la donnée provenait de l’entrée standard et non d’un fichier.
Deux observations tiennent dans cet exemple. La première : la même entrée donnera indéfiniment la même sortie, sur cette machine comme sur une autre. La seconde : le passage d’une minuscule à une majuscule, soit un seul bit de différence dans le premier octet, produit une empreinte sans aucun rapport visible avec la précédente.
Les quatre propriétés attendues d’une fonction de hachage cryptographique
Toute fonction qui réduit une donnée à une valeur courte n’est pas cryptographique. Un CRC32 (Cyclic Redundancy Check sur 32 bits) détecte très bien une erreur de transmission, mais fabriquer volontairement deux fichiers de même CRC32 est à la portée d’un ordinateur portable. Le qualificatif « cryptographique » suppose quatre propriétés.
Le déterminisme
La même entrée produit toujours la même empreinte. C’est ce qui autorise à comparer deux empreintes pour conclure que deux données sont identiques. Attention à ce qui est réellement haché : ce sont des octets, pas un sens. Un texte accentué encodé en UTF-8 et le même texte encodé en ISO-8859-1 donnent deux empreintes différentes ; un fichier texte enregistré avec des fins de ligne Windows (retour chariot puis saut de ligne) diffère du même fichier en fins de ligne Unix. Une empreinte qui ne correspond pas s’explique très souvent ainsi.
La résistance à la préimage
Étant donné une empreinte, il doit être infaisable de retrouver une donnée qui la produit. C’est la propriété que l’introduction appelle le caractère unidirectionnel. Il n’existe pas d’opération inverse : la seule voie connue est d’essayer des entrées jusqu’à retrouver l’empreinte, ce qui représente de l’ordre de 2256 tentatives pour SHA-256.
Cette garantie a une limite que les débutants sous-estiment : elle porte sur la fonction, pas sur la donnée. Si l’entrée appartient à un ensemble petit ou prévisible — une date de naissance, un numéro de téléphone, une adresse électronique, un mot de passe courant — l’attaquant n’a pas besoin de casser quoi que ce soit. Il énumère les candidats, les hache, et compare. Hacher une donnée devinable ne la protège pas.
Une variante de cette propriété est la résistance à la seconde préimage : à partir d’une donnée connue, il doit être infaisable d’en construire une autre, différente, qui produise la même empreinte.
La résistance aux collisions
Une collision est un couple de deux entrées différentes ayant la même empreinte. Des collisions existent nécessairement : les entrées possibles sont en nombre illimité, les sorties sont en nombre fini. La propriété ne demande donc pas qu’il n’en existe pas, mais qu’on ne sache pas en fabriquer.
Le coût de recherche d’une collision est nettement inférieur à celui d’une préimage, à cause de ce qu’on appelle le paradoxe des anniversaires : pour une empreinte de n bits, il faut de l’ordre de 2n/2 essais. Pour SHA-256, la sécurité réelle contre les collisions est donc de l’ordre de 2128, et non de 2256. C’est cette borne, moitié moindre, qui explique pourquoi les empreintes trop courtes ont été abandonnées.
L’effet avalanche
Modifier un seul bit de l’entrée doit changer environ la moitié des bits de la sortie, sans régularité exploitable. L’exemple de bonjour et Bonjour ci-dessus le montre. La conséquence pratique est importante : on ne peut rien déduire de la ressemblance entre deux empreintes. Deux fichiers presque identiques ont des empreintes totalement dissemblables. La comparaison d’empreintes est une réponse en tout ou rien, jamais une mesure de proximité.
Hachage, chiffrement, encodage : trois opérations distinctes
C’est la confusion la plus fréquente en début d’apprentissage, et elle a des conséquences réelles sur la sécurité d’une application. Les trois opérations transforment une donnée en une autre suite de caractères, mais elles ne servent pas au même usage et n’offrent pas les mêmes garanties.
- L’encodage change la représentation d’une donnée. Il est réversible par n’importe qui, sans secret, et c’est son but. Base64, par exemple, représente des octets quelconques à l’aide de 64 caractères imprimables, pour les faire passer dans un courrier électronique ou un document JSON. L’encodage n’apporte aucune confidentialité.
- Le chiffrement rend une donnée illisible pour qui ne possède pas la clé, et parfaitement lisible pour qui la possède. Il est réversible dans les deux sens, par conception. AES (Advanced Encryption Standard) et ChaCha20 sont des algorithmes de chiffrement.
- Le hachage n’est réversible par personne, pas même par celui qui a calculé l’empreinte. Il n’y a pas de clé et pas de déchiffrement. La sortie a une taille fixe, indépendante de l’entrée.
$ printf 'bonjour' | base64
Ym9uam91cg==
$ echo 'Ym9uam91cg==' | base64 -d
bonjourDeux formulations courantes sont donc à écarter. « Mot de passe crypté » ne décrit rien d’utilisable : si un mot de passe peut être retrouvé, c’est qu’il a été chiffré et que la clé est stockée quelque part, ce qui ramène le problème au stockage de la clé. Et un mot de passe encodé en Base64 est un mot de passe en clair, simplement moins lisible à l’œil.
Calculer une empreinte sous Linux et sous Windows
Sous Linux
$ printf 'bonjour\n' > exemple.txt
$ sha256sum exemple.txt
9cec0af545144159bac85c7b908d5e0b9b0ef961497401c5ad8da26f065ad926 exemple.txt
$ md5sum exemple.txt
94baaad4d1347ec6e15ae35c88ee8bc8 exemple.txt
$ openssl dgst -sha256 exemple.txt
SHA2-256(exemple.txt)= 9cec0af545144159bac85c7b908d5e0b9b0ef961497401c5ad8da26f065ad926Le paquet GNU coreutils, présent sur la quasi-totalité des distributions — les systèmes bâtis sur BusyBox, comme Alpine, n’en fournissent qu’un équivalent restreint —, fournit sha256sum, sha512sum, sha1sum, md5sum et b2sum. La commande openssl dgst couvre davantage d’algorithmes, par exemple openssl dgst -sha3-256. Le libellé qu’elle imprime dépend de la version installée : les versions récentes écrivent SHA2-256(...) là où les anciennes écrivaient SHA256(...). La liste des algorithmes réellement disponibles sur la machine s’obtient avec openssl dgst -list.
Sous Windows
PS> Get-FileHash .\exemple.txt
Algorithm Hash Path
--------- ---- ----
SHA256 9CEC0AF545144159BAC85C7B908D5E0B9B0EF961497401C5AD8DA26F065AD926 C:\...\exemple.txt
PS> Get-FileHash .\exemple.txt -Algorithm MD5La commande PowerShell Get-FileHash utilise SHA-256 par défaut ; le paramètre -Algorithm accepte notamment SHA1, SHA256, SHA384, SHA512 et MD5. Sa sortie est en majuscules alors que sha256sum écrit en minuscules : c’est la même valeur, la comparaison doit simplement ignorer la casse. Une variante en ligne de commande classique existe également avec certutil -hashfile exemple.txt SHA256.
Une remarque de méthode : comparer 64 caractères hexadécimaux à l’œil, ou en regardant seulement le début et la fin, ne constitue pas une vérification. La comparaison doit être faite par la machine, comme dans la section suivante.
À quoi le hachage sert réellement
Vérifier un téléchargement
Les éditeurs publient à côté de leurs fichiers un fichier d’empreintes, souvent nommé SHA256SUMS, contenant une ligne par fichier. La commande sha256sum sait relire ce format et faire la comparaison elle-même, avec l’option -c.
$ sha256sum exemple.txt > SHA256SUMS
$ sha256sum -c SHA256SUMS
exemple.txt: RéussiLe mot affiché dépend de la langue du système : un système configuré en anglais imprime OK. En cas de différence, la commande signale l’échec et renvoie un code de retour non nul, ce qui permet de l’employer dans un script.
La portée de cette vérification mérite d’être comprise. Elle prouve que le fichier reçu est bien celui dont l’empreinte a été publiée. Elle protège donc contre une corruption accidentelle : transfert interrompu, miroir défectueux, support abîmé. Face à un adversaire qui contrôle le serveur, elle ne suffit pas : celui qui peut remplacer le fichier peut généralement remplacer aussi la page qui affiche l’empreinte. C’est pourquoi les projets sérieux publient une signature électronique du fichier d’empreintes, vérifiable avec une clé publique obtenue par un autre canal.
Identifier un fichier par son contenu
Une empreinte constitue un identifiant de contenu : aucune collision n’étant connue pour SHA-256, on conclut en pratique que deux fichiers de noms différents ayant la même empreinte SHA-256 ont le même contenu. Cette propriété est utilisée par le gestionnaire de versions Git, qui nomme ses objets internes par leur empreinte, par les systèmes de sauvegarde qui évitent de stocker deux fois un bloc identique, et par les bases d’empreintes de logiciels malveillants.
Signer un document
Une signature électronique ne porte pas sur le document lui-même mais sur son empreinte : celle-ci est courte, de taille fixe, et rapide à calculer, alors que les opérations de signature sont coûteuses. Cette construction explique pourquoi la résistance aux collisions n’est pas une préoccupation théorique : si un attaquant sait fabriquer deux documents de même empreinte, il fait signer le premier et présente le second avec la même signature valide.
Authentifier un message
Un HMAC (keyed-Hash Message Authentication Code, code d’authentification de message à clé) combine une fonction de hachage et une clé secrète pour produire une valeur qui prouve à la fois l’intégrité du message et la connaissance de la clé. Il ne faut pas improviser cette construction en concaténant simplement la clé et le message : SHA-256 et SHA-512, bâties sur le schéma dit de Merkle-Damgård, sont sujettes à l’extension de longueur (les variantes tronquées de la même famille, comme SHA-384, y échappent), qui permet à un tiers d’allonger le message et de recalculer une empreinte valide sans connaître la clé. HMAC est précisément conçu pour empêcher cela. SHA-3 et BLAKE2 ne présentent pas cette faiblesse.
L’état des algorithmes en pratique
MD5 (Message-Digest Algorithm 5, 128 bits) est cassé pour la résistance aux collisions : la fabrication de deux entrées de même empreinte a été démontrée en 2004 et se calcule aujourd’hui en quelques secondes sur une machine ordinaire. MD5 ne doit plus servir dès qu’un adversaire peut influencer le contenu haché : signature, contrôle d’intégrité de mise à jour, identification de fichier dans un contexte de sécurité.
SHA-1 (160 bits) a suivi le même chemin : une collision complète a été publiée en 2017 sous le nom SHAttered, sous la forme de deux fichiers PDF différents de même empreinte, puis une collision à préfixes choisis en 2020, plus proche encore des scénarios d’usurpation réels. SHA-1 a été retiré des certificats des autorités de certification publiques et proscrit pour les nouvelles signatures ; il subsiste encore dans des systèmes anciens.
Une précision qui évite un contresens : dans les deux cas, c’est la résistance aux collisions qui est tombée, pas la résistance à la préimage. Retrouver une donnée à partir d’une empreinte MD5 reste hors de portée par le calcul direct — ce qui n’empêche pas de la retrouver par énumération lorsque la donnée est devinable, comme expliqué plus haut. Cette nuance n’excuse pas l’usage de MD5 ; elle explique simplement ce qui est cassé et ce qui ne l’est pas.
Trois familles sont employées sans réserve publiée à ce jour (état des travaux connus au moment de la rédaction, en 2026). SHA-2 regroupe notamment SHA-224, SHA-256, SHA-384 et SHA-512, aucune collision n’y est connue et SHA-256 constitue le choix par défaut raisonnable pour l’intégrité. SHA-3, issu de l’algorithme Keccak et normalisé en 2015, repose sur une construction différente, dite en éponge ; il n’est pas destiné à remplacer SHA-2 mais à offrir une solution de repli qui ne partagerait pas ses éventuelles faiblesses. BLAKE2 et BLAKE3 sont rapides en logiciel et se rencontrent surtout dans les outils de sauvegarde et de déduplication ; la commande b2sum disponible sous Linux calcule un BLAKE2b de 512 bits par défaut.
Le cas particulier des mots de passe
Pourquoi un SHA-256 nu ne convient pas
Un mot de passe n’est jamais stocké en clair. On stocke une empreinte, et à chaque connexion on recalcule l’empreinte du mot de passe saisi pour la comparer à celle enregistrée. Le réflexe du débutant est d’utiliser SHA-256. Il conduit à une base de données que l’on ouvre en quelques heures.
La raison tient à une qualité de SHA-256 devenue ici un défaut : sa rapidité. Une carte graphique de jeu calcule plusieurs milliards d’empreintes SHA-256 par seconde — ordre de grandeur constaté en 2026, en hausse à chaque génération de matériel. Comme les mots de passe réellement choisis par les utilisateurs se concentrent sur un ensemble restreint de candidats, parcourir des listes de plusieurs centaines de millions de mots de passe déjà divulgués est immédiat. S’ajoute l’effet du déterminisme : deux comptes ayant le même mot de passe présentent la même empreinte, ce qui se lit directement dans la base et désigne les mots de passe les plus répandus. Enfin, des tables arc-en-ciel, qui conservent sous forme condensée des chaînes de calculs effectués à l’avance, permettent de retrouver un mot de passe en échangeant du stockage contre du temps de calcul, sans refaire l’attaque depuis zéro.
Le sel
Le sel est une valeur aléatoire, différente pour chaque compte, tirée au moment de l’inscription. Elle n’est pas secrète et se range à côté de l’empreinte, dans la même base. La fonction de hachage est appliquée à la combinaison du sel et du mot de passe. Deux effets en découlent : les tables précalculées deviennent inutilisables, puisqu’il en faudrait une par sel ; et deux comptes partageant le même mot de passe reçoivent des empreintes différentes, ce qui supprime la lecture directe évoquée ci-dessus. Le sel ne ralentit en revanche pas l’attaque d’un compte unique et ciblé.
Le poivre
Le poivre est une valeur secrète, identique pour toute l’application, mêlée elle aussi au mot de passe avant hachage, mais qui n’est pas stockée dans la base de données : elle réside dans la configuration du serveur applicatif, voire dans un module matériel de sécurité. Si seule la base fuit — cas fréquent d’une injection SQL — l’attaquant ne dispose pas de l’élément nécessaire pour tester ses candidats. La contrepartie est opérationnelle : changer le poivre invalide toutes les empreintes existantes, et il faut prévoir comment le faire tourner. Le poivre est une défense supplémentaire, jamais un remplacement du sel ni d’une fonction adaptée.
Les fonctions dédiées
La bonne réponse au problème de la rapidité n’est pas de bricoler des répétitions de SHA-256, mais d’employer une fonction conçue pour le stockage de mots de passe, dont le coût de calcul est réglable.
- bcrypt, dérivé de l’algorithme de chiffrement Blowfish, est réglé par un facteur de coût qui double le temps de calcul à chaque incrément. Particularité à connaître : il ne prend en compte que les 72 premiers octets de l’entrée.
- scrypt a été conçu pour être coûteux en mémoire autant qu’en temps de calcul, afin de gêner les attaques menées sur cartes graphiques ou sur circuits spécialisés, dont la mémoire est la ressource rare.
- Argon2 a remporté la Password Hashing Competition en 2015. Il existe en trois variantes, Argon2d, Argon2i et Argon2id ; c’est Argon2id qui est recommandé par défaut. Trois paramètres se règlent : la mémoire utilisée, le nombre de passes et le degré de parallélisme.
- PBKDF2 (Password-Based Key Derivation Function 2) est plus ancien et repose sur la répétition d’une fonction pseudo-aléatoire à clé, en pratique HMAC. Il résiste moins bien au matériel spécialisé que les précédents, mais reste imposé par certains référentiels de conformité.
Le réglage des paramètres dépend du matériel et de la charge : il n’existe pas de valeur universelle, et les chiffres recopiés d’un article vieillissent mal. La règle praticable consiste à mesurer sur le serveur visé et à retenir le coût le plus élevé que l’application supporte au pic de connexions, puis à réévaluer cette mesure périodiquement. Deux points valent pour toutes ces fonctions : utiliser l’implémentation fournie par la bibliothèque standard du langage plutôt que d’en écrire une, et comparer les empreintes avec une fonction de comparaison en temps constant, afin que la durée de la réponse ne renseigne pas l’attaquant.
Points de vigilance et suite du parcours
Les commandes à retenir pour un usage quotidien tiennent en quelques lignes : sha256sum fichier et sha256sum -c SHA256SUMS sous Linux, Get-FileHash chemin sous Windows, openssl dgst -sha256 fichier lorsqu’un algorithme moins courant est nécessaire.
- Une empreinte n’est pas un secret : elle protège l’intégrité, jamais la confidentialité. Publier l’empreinte d’une donnée sensible revient souvent à publier la donnée si celle-ci est devinable.
- Une empreinte se vérifie par comparaison automatique, pas en regardant les premiers et les derniers caractères.
- Une empreinte différente de celle attendue n’indique pas toujours une attaque : encodage du texte, fins de ligne, archive comparée à son contenu décompressé sont les causes les plus fréquentes.
- Un fichier d’empreintes non signé ne démontre que l’absence de corruption accidentelle.
- MD5 et SHA-1 sont à écarter dès qu’un adversaire peut choisir le contenu haché ; SHA-256 est le choix par défaut pour l’intégrité.
- Pour un mot de passe, aucune fonction rapide ne convient : Argon2id, scrypt ou bcrypt, avec un sel unique par compte.
La suite naturelle de ce parcours porte sur trois sujets qui reposent tous sur le hachage : la signature électronique et la vérification d’une clé publique, les codes d’authentification de message de type HMAC et les jetons qui en dérivent, et les fonctions de dérivation de clé, qui transforment un mot de passe en clé de chiffrement.
Le texte d’origine de cet article n’a pas été conservé par les archives du web : la capture de la page s’arrête avant le corps. Seule son introduction subsiste, reprise ici en ouverture. Le reste a été réécrit le 9 septembre 2026, puis relu et corrigé point par point.