Quand les développeurs comparent MD5 vs SHA-256 vs bcrypt pour stocker des mots de passe, le conseil habituel est « MD5 est cassé, utilisez SHA-256 ». Ce conseil est erroné, et c'est l'erreur de sécurité la plus courante dans ce domaine. MD5 est cassé, oui. Mais SHA-256 brut est aussi un mauvais choix pour les mots de passe, pour une raison complètement différente : il est trop rapide. La bonne réponse est un algorithme délibérément lent conçu pour les mots de passe, ce qui signifie bcrypt ou Argon2.
Ce guide fait la distinction que le reste des SERP ignore. Nous verrons pourquoi les hachages rapides perdent face aux GPU, ce que le salage et les facteurs de travail font réellement, et exactement quel algorithme utiliser en 2026. Vous pouvez tester chaque type de hachage vous-même dans le navigateur au fur et à mesure.
MD5 vs SHA-256 vs bcrypt en un coup d'œil#
L'erreur fondamentale est de considérer tous les hachages comme une seule tâche. Il s'agit en réalité de deux tâches distinctes aux exigences opposées. L'intégrité des fichiers nécessite un hachage rapide. Le stockage des mots de passe nécessite un hachage lent. Confondre les deux explique pourquoi des bases de données compromises sont craquées en quelques heures.
| Algorithme | Type | Vitesse | Sel intégré | Sûr pour les mots de passe ? | Idéal pour |
|---|---|---|---|---|---|
| MD5 | Hachage rapide | Extrêmement rapide | Non | Non (cassé) | Rien lié à la sécurité |
| SHA-1 | Hachage rapide | Très rapide | Non | Non (cassé) | Compatibilité héritée uniquement |
| SHA-256 | Hachage rapide | Très rapide | Non | Non (trop rapide) | Sommes de contrôle, intégrité, signatures |
| bcrypt | Hachage lent (KDF) | Ajustable, lent | Oui | Oui | Stockage de mots de passe |
| Argon2id | Hachage lent (KDF) | Ajustable, lent | Oui | Oui (meilleur actuel) | Stockage de mots de passe |
| PBKDF2 | Hachage lent (KDF) | Ajustable, lent | Oui (vous l'ajoutez) | Oui (acceptable) | Environnements sous contrainte FIPS |
À retenir : SHA-256 est excellent pour la tâche pour laquelle il a été conçu (prouver qu'un fichier n'a pas été modifié) et dangereux pour une tâche pour laquelle il n'a jamais été conçu (résister au matériel de craquage de mots de passe). « Hachage sécurisé » ne signifie pas « sécurisé pour les mots de passe ».
Le mot « sécurisé » est à l'origine de la plupart des confusions. SHA-256 fait partie de la famille SHA-2, et il est cryptographiquement sécurisé dans le sens où il est impossible de trouver des collisions ou de l'inverser mathématiquement. C'est cette propriété dont l'intégrité des fichiers a besoin. Le stockage des mots de passe nécessite quelque chose de totalement différent : une résistance au forçage brut à grande échelle.
Pourquoi MD5 est cassé (et SHA-1 avec lui)#
MD5 échoue sur deux fronts. Premièrement, il est cassé au niveau des collisions : les chercheurs peuvent délibérément produire deux entrées différentes avec le même condensé MD5, ce qui détruit sa valeur pour les signatures et les certificats. SHA-1 a subi le même sort avec les travaux pratiques sur les collisions publiés en 2017.
Deuxièmement, et c'est plus pertinent pour les mots de passe, MD5 est extrêmement rapide. Un GPU moderne peut calculer des milliards de hachages MD5 par seconde. Cette vitesse est un atout pour une somme de contrôle et une catastrophe pour un hachage de mot de passe.
Voici ce que cette vitesse signifie en pratique. Si un site stocke les mots de passe en MD5 brut et que la base de données fuit, un attaquant avec une seule carte graphique grand public peut tester un énorme dictionnaire de mots de passe courants contre chaque compte presque instantanément. Ajoutez une table arc-en-ciel précalculée (une énorme table de correspondance hachage-texte clair) et les hachages MD5 non salés des mots de passe courants s'inversent en millisecondes.
- MD5 : cassé au niveau des collisions, beaucoup trop rapide, pas de sel. Ne l'utilisez jamais pour la sécurité.
- SHA-1 : cassé au niveau des collisions depuis 2017, trop rapide. Déprécié partout.
- La leçon : "cassé" ici concerne en partie les collisions et en partie la vitesse brute.
Vous pouvez toujours utiliser MD5 ou SHA-256 en toute sécurité pour les vérifications d'intégrité non adversariales (ce fichier a-t-il été téléchargé intact ?). C'est de l'intégrité, pas de l'authenticité, et non du stockage de mots de passe. Pour tout ce qu'un attaquant voudrait falsifier ou casser, MD5 est exclu.
Le piège SHA-256 : sécurisé mais trop rapide pour les mots de passe#
C'est la partie que la plupart des comparaisons oublient. SHA-256 n'est pas cassé par collision. C'est un hachage cryptographique vraiment solide. Alors pourquoi est-ce le mauvais outil pour les mots de passe ?
Parce qu'il est rapide intentionnellement. SHA-256 a été conçu pour que les systèmes puissent hacher de grandes quantités de données rapidement afin de vérifier l'intégrité. Une machine GPU haut de gamme peut calculer de l'ordre de milliards de hachages SHA-256 par seconde. Quand l'algorithme est rapide, la machine de force brute de l'attaquant l'est aussi.
Le craquage de mots de passe est un jeu de devinettes hors ligne. Une fois que l'attaquant a votre base de données de hachages, rien ne limite leur vitesse. Ils ne se connectent pas à votre site une tentative à la fois. Ils exécutent vos hachages contre des listes de mots et des règles de mutation sur du matériel dédié. Plus votre fonction de hachage est rapide, plus ils obtiennent de suppositions par seconde, et moins cher chaque mot de passe craqué devient.
Le salage aide, mais ne résout pas la vitesse#
Une contre-argument courante est "il suffit de saler votre SHA-256". Un sel est une valeur aléatoire unique stockée à côté de chaque hachage et mélangée à l'entrée avant le hachage. Le salage est essentiel, et il fait deux choses réelles :
- Il neutralise les tables arc-en-ciel, car une table précalculée est inutile contre des sels aléatoires par utilisateur.
- Il garantit que deux utilisateurs avec le même mot de passe obtiennent des hachages différents, donc craquer l'un ne craque pas l'autre.
Mais le salage ne fait rien pour la vitesse. Un attaquant craque toujours chaque hachage SHA-256 salé un par un à des milliards de suppositions par seconde. Le sel supprime le raccourci de précalcul en masse ; il ne rend pas la fonction sous-jacente lente. C'est pourquoi "SHA-256 salé" est meilleur que SHA-256 nu et toujours pas assez bon pour les mots de passe.
Le modèle mental : le sel protège contre le précalcul. Un algorithme lent protège contre le débit brut de force brute. Vous avez besoin des deux, et SHA-256 ne vous en donne qu'un.
Ce que bcrypt fait différemment : lent intentionnellement#
bcrypt a été conçu en 1999 spécifiquement pour le stockage de mots de passe, et son idée centrale est l'opposé de MD5 et SHA-256 : il est délibérément et ajustablement lent. bcrypt regroupe trois choses dont un hachage de mot de passe a besoin.
- Un sel intégré. bcrypt génère et stocke automatiquement un sel par hachage, vous ne pouvez donc pas oublier d'en ajouter un.
- Un facteur de travail (le « coût »). C'est un nombre que vous définissez et qui contrôle le nombre d'itérations internes que bcrypt exécute. Chaque incrément d'une unité double approximativement le temps de calcul d'un hachage.
- Une conception adaptative. À mesure que le matériel devient plus rapide, vous augmentez le facteur de travail pour maintenir le hachage lent, sans changer d'algorithme.
Une chaîne de hachage bcrypt porte ses propres paramètres. Un hachage typique ressemble à $2b$12$R9h/cIPz0gi..., où $2b$ est la version bcrypt, 12 est le facteur de travail (coût), et le reste est le sel et le digest combinés. Ce format auto-descriptif signifie que la vérification nécessite uniquement le hachage stocké, pas une colonne de sel séparée.
L'intérêt du facteur de travail est de rendre chaque tentative de devinette coûteuse. Si un hachage bcrypt prend un quart de seconde à calculer, un attaquant qui pourrait faire des milliards de suppositions SHA-256 par seconde est désormais réduit à quelques suppositions bcrypt par seconde par cœur. La même liste de mots qui craque SHA-256 en minutes pourrait prendre des années contre un bcrypt bien configuré.
Choisir un facteur de travail bcrypt#
Le facteur de travail est un compromis entre la sécurité et la latence de connexion de votre propre serveur. Définissez-le de sorte qu'un seul hachage prenne un temps notable mais tolérable sur votre matériel, généralement réglé pour se situer entre 0,1 et 0,5 seconde par hachage.
- Un coût plus élevé est plus sûr mais ralentit chaque connexion et chaque inscription.
- Effectuez des tests de performance sur votre matériel de production réel, pas sur votre ordinateur portable. Les serveurs plus rapides peuvent supporter un coût plus élevé.
- Réévaluez chaque année. Le matériel s'améliore, donc un coût qui était pénible pour les attaquants en 2020 est moins cher aujourd'hui.
bcrypt a également une particularité à connaître : il tronque l'entrée à 72 octets. Si vous prenez en charge des phrases de passe très longues ou des mots de passe pré-hachés (un modèle utilisé par certaines équipes), testez ce comportement pour ne pas ignorer silencieusement les caractères au-delà de la limite.
Où se situe Argon2 (et PBKDF2)#
bcrypt est excellent et reste un choix parfaitement défendable en 2026. Mais la recommandation actuelle des guides de sécurité comme la fiche de stockage des mots de passe de l'OWASP est Argon2id, le vainqueur du concours de hachage de mots de passe de 2015.
Argon2id améliore bcrypt en étant gourmand en mémoire. Le facteur de travail de bcrypt coûte du temps CPU, mais utilise peu de mémoire, ce qui permet aux attaquants d'empiler de nombreux cœurs de craquage bcrypt sur du matériel bon marché. Argon2id permet de régler trois paramètres : le coût en temps (itérations), le coût en mémoire (quantité de RAM nécessaire par hachage) et le parallélisme. Forcer chaque tentative à consommer une mémoire significative réduit l'avantage des GPU et ASIC qui rendent le craquage bon marché.
| Algorithme | Résiste au craquage GPU | Gourmand en mémoire | Quand le choisir |
|---|---|---|---|
| Argon2id | Fort | Oui | Nouveaux systèmes ; recommandation par défaut actuelle |
| bcrypt | Fort | Non | Mature, éprouvé ; acceptable pour les systèmes existants |
| scrypt | Fort | Oui | Alternative valide gourmande en mémoire si Argon2 indisponible |
| PBKDF2 | Modéré | Non | Exigences de conformité FIPS-140 ; utiliser des itérations élevées |
PBKDF2 mérite d'être mentionné car il apparaît dans les environnements réglementés. Il est plus ancien et non gourmand en mémoire, donc il résiste moins bien aux GPU que bcrypt ou Argon2. Mais il est approuvé FIPS, ce qui compte pour le gouvernement et certains travaux en entreprise. Si vous devez utiliser PBKDF2, poussez le nombre d'itérations très haut (centaines de milliers à millions, ajusté à votre budget de latence).
La version courte de l'arbre de décision :
- Nouveau projet sans contraintes : utilisez Argon2id.
- Système existant déjà sur bcrypt et fonctionnel : bcrypt est bien, gardez-le, augmentez le coût avec le temps.
- Environnement FIPS ou conformité stricte : PBKDF2 avec un nombre d'itérations très élevé.
- Jamais : MD5, SHA-1, SHA-256 brut, SHA-512 brut, ou tout hachage rapide non salé.
Testez chaque hachage vous-même#
Lire sur les hachages est une chose. Les voir en action en est une autre, et cela rend la différence de vitesse concrète. Vous pouvez générer des condensés MD5, SHA-1, SHA-256 et SHA-512 d'une même entrée dans le navigateur pour observer comment chaque algorithme transforme le texte.
Collez une chaîne exemple comme correct horse battery staple dans le générateur de hachage gratuit et regardez-le produire chaque condensé instantanément. Ce résultat instantané est exactement le problème des hachages rapides pour les mots de passe : si votre navigateur calcule un condensé SHA-256 sans délai perceptible, imaginez une ferme de GPU en faisant des milliards par seconde contre une base de données divulguée.
Quelques choses à essayer pendant vos tests :
- Hachez le même mot deux fois. Notez que MD5 et SHA-256 donnent la même sortie à chaque fois, ce qui explique pourquoi ils ont besoin d'un sel externe et pourquoi les tables arc-en-ciel fonctionnent contre eux.
- Changez un seul caractère. Le condensé entier change complètement (effet avalanche), ce qui est bon pour les vérifications d'intégrité.
- Comparez les longueurs des condensés. SHA-256 est plus long que MD5, mais la longueur seule ne le rend pas sûr pour les mots de passe. La vitesse est le vrai problème.
Remarque : un outil de hachage rapide côté navigateur est le bon moyen d'apprendre ce que ces algorithmes produisent, mais ce n'est pas là où vous devriez générer des hachages de mots de passe en production. bcrypt et Argon2 doivent être côté serveur dans votre bibliothèque d'authentification, jamais dans du JavaScript client.
Pendant que vous réfléchissez à la sécurité des identifiants, il vaut la peine de vérifier la résistance de vos propres mots de passe. Un mot de passe fort et un hachage lent fonctionnent ensemble : les mots de passe faibles cèdent à n'importe quel hachage, et un excellent hachage ne peut pas sauver complètement un mot de passe présent dans toutes les listes de mots. Testez-en quelques-uns avec le vérificateur de force de mot de passe pour voir comment la devinabilité et l'entropie entrent en jeu, et générez-en des vraiment aléatoires avec le générateur de mots de passe sécurisé pour que les mathématiques du craquage soient de votre côté.
Erreurs courantes à éviter#
La théorie est simple, mais les mêmes erreurs d'implémentation reviennent sans cesse. Méfiez-vous de celles-ci.
- Utiliser SHA-256 parce qu'il est "plus sécurisé que MD5." Il l'est, contre les collisions. Il est toujours trop rapide pour les mots de passe. C'est le piège que cet article entier existe pour signaler.
- Inventer votre propre schéma comme
sha256(sha256(motdepasse) + sel). Empiler des hachages rapides ne crée pas un hachage lent. Utilisez une vraie KDF de mot de passe. - Stocker le sel de manière incorrecte ou réutiliser un sel global. Les sels doivent être uniques et aléatoires par utilisateur. bcrypt et Argon2 gèrent cela pour vous, ce qui est une raison de plus de les utiliser.
- Définir un facteur de travail une fois et ne jamais l'augmenter. Un coût qui ralentissait les attaquants il y a des années est maintenant bon marché. Revenez-y.
- Hacher les mots de passe en JavaScript côté client. Le hachage doit se faire sur le serveur. Un hachage côté client devient simplement le nouveau mot de passe qu'un attaquant rejoue.
Si vous gérez également des jetons plutôt que seulement des mots de passe stockés, la même logique "utilisez la bonne primitive" s'applique aux signatures et à la vérification. Notre guide sur décoder vs vérifier un JWT couvre une erreur étroitement liée : faire confiance à un jeton que vous avez seulement décodé mais jamais vérifié cryptographiquement.
Le verdict sur MD5 vs SHA-256 vs bcrypt#
Pour le stockage des mots de passe, le classement est sans appel. MD5 est cassé et bien trop rapide. SHA-256 est cryptographiquement solide mais reste trop rapide, même salé, donc il cède face au brute force par GPU dès que votre base de données fuit. bcrypt et Argon2id sont volontairement lents, salent automatiquement, et vous permettent d'augmenter le coût à mesure que le matériel progresse, ce qui est exactement ce qu'exige le stockage des mots de passe.
Alors quand on vous pose la question MD5 vs SHA-256 vs bcrypt pour les mots de passe, la réponse est bcrypt ou Argon2id, à chaque fois. Réservez SHA-256 pour ce pour quoi il est vraiment excellent, comme l'intégrité des fichiers et les sommes de contrôle, et ne laissez jamais une étiquette de « hachage sécurisé » vous piéger en utilisant un algorithme rapide là où un lent s'impose. Testez chaque condensé dans le générateur de hachage gratuit pour concrétiser la différence de vitesse, puis gardez les algorithmes lents et spécifiques aux mots de passe dans votre couche d'authentification, là où ils doivent être.
Foire aux questions#
SHA-256 est-il sécurisé pour les mots de passe ? Non, même si SHA-256 est un hachage cryptographique solide et non cassé. Le problème est la vitesse : SHA-256 est conçu pour être rapide, donc un attaquant disposant d'une base de données volée peut essayer des milliards de combinaisons par seconde sur un GPU. Le salage protège contre les tables arc-en-ciel mais ne ralentit pas l'algorithme. Pour les mots de passe, utilisez plutôt une fonction délibérément lente comme bcrypt ou Argon2id.
Pourquoi bcrypt est-il meilleur que SHA-256 pour les mots de passe ? bcrypt est intentionnellement lent et ajustable, tandis que SHA-256 est intentionnellement rapide. bcrypt intègre un sel et un facteur de travail réglable, ce qui rend chaque tentative de mot de passe coûteuse en temps et en argent pour l'attaquant. À mesure que le matériel s'améliore, vous augmentez le facteur de travail pour maintenir le cassage coûteux. SHA-256 offre aux attaquants des tentatives bon marché et à haut débit, ce qui est l'inverse de ce dont le stockage de mots de passe a besoin.
Dois-je utiliser bcrypt ou Argon2 en 2026 ? Les deux sont solides. Argon2id est actuellement la meilleure recommandation car il est résistant à la mémoire, ce qui réduit l'avantage des GPU et ASIC qui rend le cassage bon marché. bcrypt reste un choix parfaitement défendable et éprouvé, surtout si votre système l'utilise déjà. Pour un nouveau projet sans contraintes de conformité, optez par défaut pour Argon2id ; si vous utilisez déjà bcrypt et ajustez le coût, il n'y a pas de raison urgente de migrer.
Le salage suffit-il à rendre SHA-256 sûr pour les mots de passe ? Non. Le salage est nécessaire et vous devez toujours le faire, mais il ne résout qu'un problème : il empêche les tables arc-en-ciel précalculées et garantit que des mots de passe identiques produisent des hachages différents. Le salage n'affecte pas la vitesse de l'algorithme, donc un attaquant peut toujours casser chaque hachage SHA-256 salé à des milliards de tentatives par seconde. Vous avez besoin à la fois d'un sel unique et d'un algorithme lent, ce que fournissent exactement bcrypt et Argon2.
MD5 est-il sûr pour quoi que ce soit ? Uniquement pour les vérifications d'intégrité non liées à la sécurité, comme confirmer qu'un fichier a été téléchargé sans erreur. MD5 est vulnérable aux collisions, il ne doit donc jamais être utilisé pour les signatures numériques, les certificats, les mots de passe ou tout ce qu'un attaquant pourrait vouloir falsifier ou casser. Même pour l'intégrité de fichiers face à un adversaire réel, préférez SHA-256. Vous pouvez comparer MD5 à d'autres condensés avec un générateur de hachage gratuit.
Qu'est-ce que le facteur de travail dans bcrypt ? Le facteur de travail (ou coût) est un nombre qui contrôle le nombre d'itérations internes effectuées par bcrypt. Chaque incrément d'une unité double approximativement le temps de calcul d'un hachage. Vous le définissez pour qu'un hachage prenne une fraction de seconde petite mais perceptible sur votre matériel de production, ce qui maintient les connexions rapides pour vous tout en ralentissant le cassage massif pour les attaquants. Augmentez-le avec le temps à mesure que le matériel devient plus rapide.
