Hachage expliqué : MD5, SHA, et quand utiliser chacun
Les fonctions de hachage transforment les données en empreintes. Voici comment elles fonctionnent et pourquoi MD5 n'est pas encore mort.
Tu télécharges un fichier. Le site web affiche une somme de contrôle MD5. Tu es censé la vérifier d'une manière ou d'une autre. Mais pourquoi ? Et quelle est la différence entre MD5 et SHA-256 ?
Les fonctions de hachage sont partout dans les logiciels. Les comprendre t'aide à les utiliser correctement.
Ce que fait le hachage
Une fonction de hachage prend n'importe quelle entrée et produit une sortie de taille fixe. Toujours la même sortie pour la même entrée. Change un bit de l'entrée, et la sortie change complètement.
"hello" → 5d41402abc4b2a76b9719d911017c592 (MD5)
"Hello" → 8b1a9953c4611296a827abf8c47804d7 (MD5)
Une majuscule change tout le hash. C'est le but.
Hash vs Chiffrement
Le hachage est à sens unique. Tu ne peux pas inverser un hash pour obtenir les données originales.
Le chiffrement est bidirectionnel. Avec la bonne clé, tu peux déchiffrer et récupérer l'original.
Si quelqu'un dit qu'il peut "déchiffrer" un hash MD5, soit il le craque (essaye des entrées jusqu'à ce qu'une corresponde) soit il est confus sur le fonctionnement du hachage.
Les algorithmes courants
MD5 - Sortie 128 bits. Rapide mais cryptographiquement cassé. OK pour les sommes de contrôle, pas pour la sécurité.
SHA-1 - 160 bits. Aussi cassé pour un usage cryptographique. Les systèmes legacy l'utilisent encore.
SHA-256 - 256 bits. Standard actuel. Utilise celui-ci quand la sécurité compte.
SHA-512 - 512 bits. Légèrement plus sécurisé, parfois plus rapide sur les systèmes 64 bits.
BLAKE2/BLAKE3 - Alternatives modernes. Plus rapides que SHA-256 avec une sécurité similaire.
Quand MD5 convient
MD5 a une mauvaise réputation parce qu'il est "cassé." Mais cassé pour la cryptographie ne signifie pas inutile.
Vérifications d'intégrité de fichiers. Vérifier qu'un téléchargement n'a pas été corrompu. Un attaquant devrait créer un fichier malveillant avec le même hash, ce qui nécessite plus d'effort que ce que la plupart des attaques valent pour des contextes non sécuritaires.
Clés de cache. Hacher du contenu pour générer des identifiants uniques. Aucune implication de sécurité.
Déduplication. Trouver des fichiers dupliqués en comparant les hashs.
Quand utiliser SHA-256 ou mieux
Stockage de mots de passe. En fait, utilise bcrypt ou Argon2 à la place. Ils sont conçus pour les mots de passe.
Signatures numériques. Intégrité de documents où des adversaires pourraient tenter la contrefaçon.
Tout ce qui est critique pour la sécurité. Quand un attaquant a une incitation à trouver des collisions.
Le problème de collision
Une collision, c'est quand deux entrées différentes produisent le même hash. Les mathématiques d'anniversaire disent que les collisions deviennent probables plus tôt qu'on ne le penserait.
Pour MD5, les chercheurs ont trouvé des moyens de créer des collisions intentionnelles. Deux fichiers différents, même hash. C'est pourquoi c'est "cassé."
Pour SHA-256, aucune attaque de collision pratique n'existe. Encore.
Exemples pratiques
Vérifier les téléchargements :
sha256sum ubuntu.iso
# Compare la sortie au hash sur la page de téléchargement
Stocker des clés API : Stocke le hash, pas la vraie clé. Quand les utilisateurs soumettent une clé, hache-la et compare.
Commits Git :
Git utilise SHA-1 pour identifier les commits. C'est pourquoi les hashs de commits ressemblent à a1b2c3d4e5f6...
Ne fais pas ton propre système
N'invente jamais ton propre schéma de hachage. "MD5 deux fois" ou "SHA-256 avec sel ajouté" sont pires que d'utiliser des modèles établis.
Pour les mots de passe : bcrypt, scrypt, ou Argon2. Pour l'intégrité : SHA-256. Pour la vitesse : BLAKE3.
Les experts ont déjà résolu ça.
Les fonctions de hachage sont simples en concept mais nuancées dans l'application. Choisis le bon algorithme pour le travail, et n'utilise pas de hachage cryptographique où une simple somme de contrôle ferait l'affaire.