Vérifier le hash d'un fichier téléchargé est l'un des réflexes de sécurité les plus simples et les plus négligés. Ce guide explique ce qu'est une fonction de hash, comment l'utiliser pour vérifier l'intégrité d'un téléchargement, et pourquoi MD5/SHA-1 ne suffisent plus pour de la sécurité.
Une fonction de hash transforme n'importe quelle donnée (un mot, un fichier de plusieurs gigaoctets, une image) en une empreinte de taille fixe, généralement représentée comme une chaîne hexadécimale. Trois propriétés la rendent utile pour vérifier l'intégrité :
Quand un éditeur logiciel publie un fichier (un installeur, une image ISO, une archive), il publie souvent aussi son hash sur la page de téléchargement. Cela permet à quiconque télécharge le fichier de vérifier qu'il n'a pas été corrompu pendant le transfert ou altéré entre le serveur d'origine et l'utilisateur final :
Si les hash ne correspondent pas, ne fais jamais confiance au fichier — supprime-le et retélécharge-le depuis la source officielle. Un hash différent peut signaler une corruption réseau, mais aussi une altération malveillante (fichier piégé, attaque de la chaîne d'approvisionnement).
| Algorithme | Taille de l'empreinte | Statut cryptographique | Usage recommandé |
|---|---|---|---|
| MD5 | 128 bits (32 caractères hex) | Cassé — collisions faciles à générer | Vérification d'intégrité non critique uniquement |
| SHA-1 | 160 bits (40 caractères hex) | Cassé — collisions démontrées (2017) | À éviter, encore présent par héritage |
| SHA-256 | 256 bits (64 caractères hex) | Solide, recommandé | Vérification d'intégrité et usages cryptographiques |
| SHA-512 | 512 bits (128 caractères hex) | Solide, recommandé | Vérification d'intégrité et usages cryptographiques |
Pour vérifier l'intégrité d'un téléchargement, utilise toujours l'algorithme le plus fort proposé par la source — si un éditeur publie à la fois un MD5 et un SHA-256, préfère systématiquement le SHA-256.
Une collision se produit quand deux entrées différentes produisent le même hash. Pour MD5 et SHA-1, des chercheurs ont démontré qu'il est possible de construire intentionnellement deux fichiers différents partageant le même hash — ce qui permettrait, en théorie, de faire passer un fichier malveillant pour un fichier légitime si seul le hash est vérifié.
C'est précisément pour cette raison que MD5 et SHA-1 sont aujourd'hui déconseillés pour tout usage où la sécurité compte (signatures, certificats), même s'ils restent largement utilisés pour de la simple détection de corruption accidentelle, où le risque d'une collision intentionnelle n'est pas pertinent.
Vérifier un hash prouve que le fichier reçu correspond exactement à celui dont le hash a été publié. Cela ne prouve pas que ce fichier est lui-même légitime : si un attaquant compromet le serveur de téléchargement et remplace à la fois le fichier et le hash affiché sur la page, la vérification "réussira" alors que le fichier est piégé.
Pour une vraie garantie d'authenticité (que le fichier provient bien de l'éditeur annoncé), il faut une signature cryptographique vérifiée avec la clé publique de l'éditeur — un mécanisme différent et complémentaire du simple hash.
Sa rapidité de calcul et sa large adoption historique en font encore un standard pour la détection de corruption accidentelle (où personne ne cherche activement à provoquer une collision). Il reste en revanche à proscrire pour tout usage de sécurité réelle.
Non — le hash dépend uniquement du contenu binaire du fichier, jamais de son nom, de sa date de modification ou de ses métadonnées de système de fichiers.
Oui, systématiquement, à condition d'utiliser le même algorithme — c'est précisément le principe qui permet de vérifier l'intégrité entre deux machines sans avoir à comparer les fichiers eux-mêmes.
Oui, le calcul se fait entièrement dans le navigateur sans limite stricte de taille, mais le temps de calcul augmente avec la taille du fichier (le MD5 implémenté en JavaScript pur est plus lent que les algorithmes SHA, qui bénéficient d'une implémentation native via le navigateur).