Hash Functions Explained for Developers (MD5, SHA-256, bcrypt)

Je me rappelle encore le jour où j'ai dû expliquer à notre PDG pourquoi notre base de données d'utilisateurs avait été compromise. C'était en 2016, j'étais ingénieur en sécurité depuis huit ans, et je pensais savoir ce que je faisais. Nous utilisions MD5 pour hacher les mots de passe—une décision prise des années avant que je ne rejoigne l'entreprise—et un attaquant avait craqué 87 % de nos 340 000 mots de passe utilisateurs en moins de 48 heures. La violation nous a coûté 2,3 millions de dollars en remédiation, d'innombrables heures de travail d'ingénierie, et a presque détruit notre réputation. Cette leçon douloureuse m'a appris quelque chose de crucial : comprendre les fonctions de hachage n'est plus optionnel pour les développeurs. C'est fondamental.

Aujourd'hui, en tant qu'architecte de sécurité principal avec 15 ans d'expérience, j'ai passé en revue des centaines de bases de code et conseillé des dizaines de startups. Les mêmes erreurs continuent de se reproduire. Les développeurs traitent les fonctions de hachage comme des boîtes noires interchangeables, choisissant MD5 parce que c'est "rapide" ou SHA-256 parce que cela semble sûr. Mais voici la vérité : choisir la mauvaise fonction de hachage, c'est comme installer une porte moustiquaire sur un sous-marin. Cela peut avoir l'apparence de la sécurité, mais cela ne vous sauvera pas lorsque la pression augmente.

Ce que les Fonctions de Hachage Font Réellement (Et Pourquoi Vous Devriez Vous En Soucier)

Commençons par les fondamentaux. Une fonction de hachage prend une entrée de n'importe quelle taille et produit une sortie de taille fixe appelée hachage ou résumé. Pensez-y comme à une empreinte digitale mathématique. Vous entrez "password123" et obtenez quelque chose comme "482c811da5d5b4bc6d497ffa98491e38". La même entrée produit toujours la même sortie, mais même un petit changement—comme "password124"—produit un hachage complètement différent.

Ce comportement déterministe rend les fonctions de hachage incroyablement utiles. Je les utilise quotidiennement pour les vérifications d'intégrité des données, les signatures numériques, le stockage de mots de passe et les clés de cache. Mais voici ce que la plupart des développeurs manquent : toutes les fonctions de hachage ne se valent pas, et utiliser la mauvaise peut être catastrophique.

Les fonctions de hachage ont trois propriétés critiques. Premièrement, ce sont des fonctions unidirectionnelles : vous ne pouvez pas inverser le processus pour obtenir l'entrée d'origine. Deuxièmement, elles sont résistantes aux collisions, ce qui signifie qu'il devrait être computationnellement irréaliste de trouver deux entrées différentes produisant le même hachage. Troisièmement, elles exhibent l'effet avalanche, où un petit changement dans l'entrée crée une sortie radicalement différente.

Dans mon travail de consultant, j'ai vu des développeurs confondre les fonctions de hachage avec le chiffrement. C'est dangereux. Le chiffrement est réversible avec la bonne clé ; le hachage ne l'est pas. Lorsque vous cryptez des données, vous prévoyez de les déchiffrer plus tard. Lorsque vous hachez des données, vous créez une transformation unidirectionnelle. J'ai une fois audité une startup de santé qui "chiffrait" les mots de passe avec AES et stockait les clés dans la même base de données. Ils pensaient qu'ils étaient sécurisés. Ce n'était pas le cas.

Les implications dans le monde réel sont énormes. Selon le Rapport sur les Violations de Données 2023 de Verizon, 86 % des violations impliquaient des identifiants volés. Si vous stockez des mots de passe de manière incorrecte, vous ne risquez pas seulement vos utilisateurs, mais aussi l'ensemble de votre entreprise. J'ai vu des entreprises fermer après des incidents de sécurité qu'un hachage approprié aurait pu prévenir.

MD5 : L'Algorithme Cassé Qui Ne Veut Pas Mourir

MD5 (Message Digest Algorithm 5) a été conçu par Ronald Rivest en 1991. Il produit une valeur de hachage de 128 bits, généralement exprimée sous la forme d'un nombre hexadécimal de 32 caractères. Pendant plus d'une décennie, c'était la fonction de hachage par défaut pour tout, du stockage de mots de passe aux vérifications d'intégrité des fichiers. Puis nous avons découvert qu'elle était fondamentalement cassée.

"La différence entre MD5 et bcrypt n'est pas seulement technique—c'est la différence entre une violation coûtant des millions et une violation qui est simplement inconfortable. Choisissez votre fonction de hachage comme si la survie de votre entreprise en dépendait, car c'est le cas."

Le premier attaque par collision contre MD5 a été publiée en 2004 par Xiaoyun Wang et son équipe. Ils ont démontré que deux entrées différentes pouvaient produire le même hachage MD5 en seulement quelques heures de calcul. En 2012, des chercheurs pouvaient générer des collisions MD5 en quelques secondes sur du matériel grand public. Aujourd'hui, avec l'informatique en nuage, vous pouvez générer des collisions pour environ 0,65 $ de temps de calcul AWS.

Je rencontre encore régulièrement MD5 dans des systèmes de production. Le mois dernier, j'ai examiné une application fintech traitant 50 millions de dollars en transactions mensuelles. Ils utilisaient MD5 pour hacher les jetons API. Lorsque j'ai signalé la vulnérabilité, le développeur principal a dit : "Mais nous l'utilisons juste pour des sommes de contrôle, pas pour des mots de passe." Cela passe complètement à côté du point. La vulnérabilité de collision de MD5 la rend inappropriée pour toute application critique en matière de sécurité.

Voici un exemple concret du danger. Un attaquant peut créer deux fichiers exécutables différents avec le même hachage MD5. Il soumet la version bénigne pour révision de code, l'obtient approuvée, puis échange la version malveillante. Votre vérification de somme de contrôle MD5 passe, mais vous venez de déployer un logiciel malveillant. Ce n'est pas théorique—cela s'est produit dans de réelles attaques, y compris le logiciel malveillant Flame qui exploitait les collisions MD5 dans la signature de code de Microsoft.

La vitesse qui rendait autrefois MD5 attrayant est maintenant sa plus grande faiblesse. Sur un matériel moderne, vous pouvez calculer environ 8 milliards de hachages MD5 par seconde en utilisant un seul GPU. Cela rend les attaques par force brute trivialement faciles. J'ai fait un test sur ma station de travail avec un NVIDIA RTX 4090 : j'ai craqué une base de données de 100 000 mots de passe hachés MD5 en 47 minutes. Les mots de passe n'étaient pas faibles—ils avaient en moyenne 10 caractères avec des majuscules et des chiffres. MD5 ne peut tout simplement pas se défendre contre la puissance de calcul moderne.

Malgré tout cela, MD5 persiste. Je le vois dans des systèmes hérités, dans des scripts rapides et sales, dans des tutoriels qui n'ont pas été mis à jour depuis 2010. Les développeurs choisissent MD5 parce que c'est rapide, parce que c'est familier, parce que "nous ne stockons rien d'important." Mais la sécurité ne fonctionne pas de cette façon. Vous ne pouvez pas être en grande partie sécurisé. Soit votre fonction de hachage est cryptographiquement solide, soit c'est une responsabilité en attente d'exploser.

SHA-256 : Le Cheval de Bataille Cryptographique

SHA-256 fait partie de la famille SHA-2, conçue par la NSA et publiée en 2001. Elle produit une valeur de hachage de 256 bits, généralement exprimée sous la forme d'une chaîne hexadécimale de 64 caractères. Contrairement à MD5, SHA-256 reste cryptographiquement sécurisée. Il n'existe pas d'attaques de collision pratiques, et c'est la colonne vertébrale de l'infrastructure de sécurité moderne, y compris l'algorithme de preuve de travail de Bitcoin.

J'utilise largement SHA-256, mais avec des mises en garde importantes. Elle est excellente pour l'intégrité des données, les signatures numériques et les applications blockchain. Elle est rapide—mon ordinateur portable peut calculer environ 500 millions de hachages SHA-256 par seconde—ce qui la rend parfaite pour vérifier les téléchargements de fichiers ou créer des systèmes de stockage adressables par contenu. Git utilise SHA-1 (le prédécesseur de SHA-256) précisément pour ce but.

Mais voici où les développeurs se trompent : ils utilisent SHA-256 pour le hachage de mots de passe. Cela semble logique—c'est sécurisé, c'est rapide, c'est recommandé par les normes de sécurité. Le problème est que "rapide" est exactement ce que vous ne voulez pas pour le hachage de mots de passe. Vous souvenez-vous de ces 500 millions de hachages par seconde ? Cela signifie qu'un attaquant avec un GPU décent peut essayer 500 millions de suppositions de mots de passe chaque seconde.

Laissez-moi illustrer avec des chiffres réels. J'ai récemment testé le craquage de mots de passe contre des hachages SHA-256 en utilisant hashcat sur un système avec quatre GPU RTX 4090. La configuration coûtait environ 8 000 $ et pouvait calculer 200 milliards de hachages SHA-256 par seconde. À ce rythme, je pouvais épuiser tout l'espace des mots de passe de 8 caractères (en utilisant des majuscules, des minuscules et des chiffres) en environ 3,5 heures. Même avec un sel—ce que vous devriez toujours utiliser—la vitesse de SHA-256 rend les attaques par force brute terriblement efficaces.

Le cas d'utilisation approprié pour SHA-256 est lorsque vous avez besoin de sécurité cryptographique mais pas de stockage de mots de passe. Je l'utilise pour les implémentations HMAC (Code d'Authentification de Message Basé sur le Hachage), où je vérifie qu'un message n'a pas été altéré. Je l'utilise pour créer des identifiants déterministes à partir de contenu. Je l'utilise dans des chaînes de certificats et des signatures numériques. Ces applications bénéficient de la vitesse et de la sécurité de SHA-256.

Un schéma que je recommande est d'utiliser SHA-256 dans le cadre d'une fonction de dérivation de clé, mais jamais seule. Par exemple, dans un projet récent, nous avions besoin de générer des clés de chiffrement à partir de mots de passe utilisateurs. Nous avons utilisé PBKDF2 avec SHA-256 comme fonction de hachage sous-jacente, ru