Ce que le hachage d’un mot de passe vous protège réellement contre

La version courte

Hacher un mot de passe protège les utilisateurs lorsque votre base de données de mots de passe est volée.

C’est son rôle principal. Ce n’est pas le seul détail, ni l’ensemble du modèle de sécurité, mais c’est la raison centrale pour laquelle nous hachons les mots de passe au lieu de les stocker directement.

Un mot de passe correctement haché est difficile à inverser. Si un attaquant obtient une copie de votre table d’utilisateurs, il ne devrait pas apprendre immédiatement que le mot de passe d’Alice est Spring2026!. À la place, il obtient un hash stocké dont la vérification contre des hypothèses demande du temps, de l’argent et du matériel.

Cette distinction compte. Le hachage des mots de passe n’est pas censé sécuriser la connexion à lui seul. Il n’arrête pas le phishing. Il n’empêche pas quelqu’un d’essayer des mots de passe divulgués sur votre formulaire de connexion. Il ne protège pas un cookie de session après la connexion. Il fait gagner du temps et réduit les dommages après une défaillance très précise : l’exposition de votre stockage de vérificateurs de mots de passe.

Si vous comprenez cette limite, vous prendrez de meilleures décisions sur les algorithmes, les facteurs de coût, les réinitialisations, la journalisation et la réponse aux incidents.

Ce qu’est un hash de mot de passe

Un hash de mot de passe est la sortie d’une fonction à sens unique appliquée à un mot de passe, généralement avec un sel unique et un algorithme de hachage de mots de passe volontairement lent.

Lorsqu’un utilisateur crée un compte, le système devrait faire à peu près ceci :

1. Recevoir le mot de passe via HTTPS.
2. Générer un sel aléatoire et unique.
3. Faire passer le mot de passe et le sel dans une fonction de hachage de mots de passe comme Argon2id, bcrypt, scrypt ou PBKDF2.
4. Stocker le nom de l’algorithme, les paramètres, le sel et le hash obtenu.
5. Supprimer le mot de passe original.

Lorsque l’utilisateur se connecte plus tard, le système répète le même processus de hachage avec le mot de passe soumis et les paramètres stockés. Si le hash obtenu correspond au hash stocké, la connexion réussit.

Le point important : l’application n’a pas besoin de connaître le mot de passe original. Elle doit seulement vérifier que le mot de passe soumis produit le résultat attendu.

C’est pourquoi stocker des mots de passe avec un chiffrement réversible est généralement le mauvais modèle. Si votre application peut déchiffrer chaque mot de passe, alors toute personne qui vole la clé de déchiffrement peut faire la même chose. Les mots de passe devraient normalement être invérifiables à rebours, et non simplement cachés.

Ce contre quoi le hachage vous protège

1. Divulgation immédiate des mots de passe après une compromission de base de données

Si un attaquant vole une base de données contenant des mots de passe en clair, les dégâts sont instantanés. Chaque mot de passe est exposé. Les utilisateurs sont à risque non seulement sur votre site, mais partout où ils ont réutilisé ce mot de passe.

Si la base de données contient des mots de passe correctement hachés, l’attaquant a plus de travail à faire. Il doit deviner des mots de passe candidats, hacher chaque hypothèse avec le bon sel et les bons paramètres, puis comparer le résultat.

Pour les mots de passe faibles, cela peut encore être rapide. Pour des mots de passe forts et uniques, cela peut être impraticable.

Le hachage transforme une divulgation catastrophique en course contre la montre : les utilisateurs peuvent-ils réinitialiser leurs mots de passe et pouvez-vous contenir l’incident avant que les attaquants en cassent beaucoup ?

Ce n’est pas parfait. Cela reste une compromission. Mais c’est un mode de défaillance considérablement meilleur.

2. Attaques de masse contre toute votre base d’utilisateurs

Les sels sont un élément clé du stockage des mots de passe parce qu’ils empêchent les attaquants de cibler efficacement de nombreux utilisateurs à la fois avec des tables précalculées.

Un sel n’est pas secret. Il est stocké avec le hash. Son rôle est l’unicité.

Si deux utilisateurs choisissent le même mot de passe, des sels uniques garantissent que leurs hashes stockés diffèrent. Cela empêche les attaquants de voir d’un seul coup d’œil que de nombreux utilisateurs partagent le même mot de passe. Cela empêche aussi les attaques classiques par rainbow table, où les attaquants utilisent d’immenses listes précalculées de correspondances entre mots de passe et hashes.

Sans sels, un hash cassé peut révéler tous les utilisateurs ayant le même mot de passe. Avec des sels, chaque hypothèse de mot de passe doit être testée séparément pour chaque utilisateur.

3. Deviner rapidement hors ligne

Une fois que les attaquants ont une base de données de mots de passe, ils peuvent deviner hors ligne. Cela signifie que vos limites de débit de connexion, CAPTCHA, blocages d’IP et systèmes de surveillance ne comptent plus. L’attaquant peut tester des hypothèses sur son propre matériel.

C’est là que le choix de l’algorithme compte.

Les fonctions de hachage généralistes comme SHA-256 et SHA-512 sont conçues pour être rapides. C’est une bonne chose pour l’intégrité des fichiers et les signatures numériques. C’est mauvais pour le stockage des mots de passe.

Les algorithmes de hachage de mots de passe sont conçus pour être lents, ajustables et parfois résistants par la mémoire. Argon2id, bcrypt, scrypt et PBKDF2 permettent tous d’ajuster des paramètres de coût afin que chaque hypothèse prenne un temps significatif.

Argon2id est largement recommandé pour les nouveaux systèmes parce qu’il peut être configuré pour exiger à la fois du temps CPU et de la mémoire, ce qui rend le craquage à grande échelle sur GPU plus coûteux. bcrypt reste courant et acceptable lorsqu’il est bien configuré, même s’il a des limites, notamment dans la gestion de la longueur des mots de passe. PBKDF2 est encore utilisé dans certains environnements guidés par la conformité, en particulier lorsque des composants validés FIPS sont requis.

Le principe est simple : rendre les connexions légitimes suffisamment rapides, tout en rendant des milliards d’hypothèses coûteuses.

Ce contre quoi le hachage ne vous protège pas

1. Phishing

Si un utilisateur saisit son mot de passe dans une fausse page de connexion, le hachage sur votre serveur n’aide pas. L’attaquant reçoit le mot de passe avant même que votre système ne le voie.

Les défenses sont différentes ici : authentification multifacteur, passkeys, sensibilisation des utilisateurs, hygiène des domaines, authentification résistante au phishing et parcours de réinitialisation de mot de passe soigneusement conçus.

Le hachage des mots de passe est un filet de sécurité pour les secrets stockés. Ce n’est pas une défense contre les utilisateurs qui se font piéger et livrent ces secrets.

2. Credential stuffing

Le credential stuffing se produit lorsque des attaquants prennent des paires nom d’utilisateur et mot de passe divulguées par un service et les essaient sur un autre.

Vos hashes de mots de passe peuvent être excellents, et le credential stuffing peut tout de même fonctionner si les utilisateurs réutilisent leurs mots de passe.

C’est une attaque en ligne contre votre formulaire de connexion, pas une attaque hors ligne contre votre base de données. Vous avez besoin de limitation de débit, de détection d’anomalies, de vérifications de mots de passe compromis, de MFA et de politiques de verrouillage raisonnables qui ne créent pas d’occasions faciles de déni de service.

La même réflexion pratique s’applique à tout formulaire exposé. Si vous passez en revue votre surface d’authentification, il vaut la peine de lire pourquoi votre formulaire de contact est votre plus grande responsabilité en matière de spam; les mécanismes diffèrent, mais la leçon est similaire : les entrées publiques ont besoin de contrôles contre les abus, pas seulement d’un code backend propre.

3. Mots de passe capturés dans les journaux ou les outils d’analytics

Le hachage n’aide que si le mot de passe en clair est supprimé rapidement et jamais copié ailleurs.

Les échecs courants incluent :

• Journaliser les corps de requête complets lors de tentatives de connexion échouées.
• Envoyer des mots de passe à des outils de surveillance des erreurs.
• Capturer des champs de mot de passe dans des produits de relecture de session.
• Inclure des identifiants dans des URLs pendant des parcours de réinitialisation ou de migration mal conçus.
• Stocker des mots de passe temporaires en clair lors d’importations.

Ces erreurs contournent entièrement le hachage des mots de passe. Si du texte en clair atterrit dans des journaux, des sauvegardes, des entrepôts de données ou des outils tiers, votre fonction de hachage n’a plus d’importance.

Traitez les champs de mot de passe comme des données toxiques. Expurgez-les avant la journalisation. Excluez-les des outils d’analytics. Gardez-les hors des URLs. Limitez l’accès aux traces de production.

4. Mauvaise sécurité des sessions

Après la connexion, le navigateur de l’utilisateur reçoit généralement un cookie ou un jeton de session. Si ce jeton est volé, l’attaquant peut ne pas avoir besoin du mot de passe du tout.

Le hachage des mots de passe ne protège pas contre le cross-site scripting, les cookies non sécurisés, la fixation de session, la génération faible de jetons ou les durées de session trop longues.

Les cookies de session méritent leur propre examen : HttpOnly, Secure, SameSite approprié, sessions à haut risque de courte durée et invalidation côté serveur lors des changements de mot de passe. Le paysage plus large de la confidentialité et des navigateurs continue aussi d’évoluer, comme l’explique ce qui a changé pour les cookies en 2026.

5. Réinitialisation de mot de passe et récupération de compte faibles

De nombreuses prises de contrôle de compte ne commencent pas par le mot de passe. Elles commencent par le parcours de réinitialisation.

Si les jetons de réinitialisation sont prévisibles, à longue durée de vie, divulgués via des en-têtes referrer ou envoyés à des comptes email compromis, le hachage des mots de passe ne vous sauvera pas.

Utilisez des jetons de réinitialisation à forte entropie, des fenêtres d’expiration courtes, un usage unique et des notifications utilisateur claires. Comme l’email est souvent le canal de récupération, l’authentification de base du domaine compte aussi. Si votre équipe traite les enregistrements DNS comme un rituel mystérieux, commencez par un tour d’horizon convivial pour développeurs de MX, SPF, DKIM et DMARC.

Le choix de l’algorithme : quoi utiliser maintenant

Pour les nouvelles applications, utilisez Argon2id si votre plateforme le prend bien en charge. C’est le gagnant de la Password Hashing Competition et il est conçu pour le stockage des mots de passe, notamment pour résister au craquage intensif sur GPU.

Une hiérarchie moderne raisonnable ressemble à ceci :

1. Argon2id pour les nouveaux systèmes lorsque disponible.
2. bcrypt lorsqu’Argon2id n’est pas pratique et que la prise en charge de bcrypt est mature.
3. scrypt lorsque la configuration résistante par la mémoire est bien prise en charge.
4. PBKDF2 lorsque des contraintes de plateforme ou de conformité l’exigent.

Évitez SHA-256, SHA-512, MD5 simples, ou une combinaison maison comme sha256(password + salt). Les fonctions de hachage rapides ne sont pas des fonctions de stockage de mots de passe. Les constructions personnalisées ingénieuses ont tendance à être pires que les standards ennuyeux.

Évitez aussi d’inventer votre propre politique de mot de passe autour de détails d’algorithme. Les utilisateurs ne tirent pas avantage d’une liste de 12 règles de composition si elle les pousse vers des schémas prévisibles. Des mots de passe plus longs et uniques, des gestionnaires de mots de passe, le filtrage des mots de passe compromis et la MFA comptent généralement davantage.

Les facteurs de coût ne sont pas à régler une fois pour toutes

Le hachage des mots de passe a des paramètres. Argon2id a la mémoire, les itérations et le parallélisme. bcrypt a un facteur de coût. PBKDF2 a un nombre d’itérations.

Ces valeurs doivent être choisies en fonction de votre environnement de production. Trop faibles, et les attaquants devinent à peu de frais. Trop élevées, et votre système de connexion devient lent ou vulnérable au déni de service.

Une cible pratique se situe souvent entre quelques dizaines et quelques centaines de millisecondes par vérification de mot de passe sur vos serveurs réels, selon le trafic et le risque. Les systèmes à haute sécurité peuvent choisir davantage. Les systèmes grand public à grande échelle peuvent nécessiter une planification soigneuse de la capacité.

Ne copiez pas un facteur de coût depuis un article de blog vieux de cinq ans. Le matériel change. Les bibliothèques changent. Votre trafic change.

Réexaminez périodiquement les paramètres et prévoyez le rehachage. Un schéma courant consiste à stocker l’algorithme et les paramètres avec chaque hash. Lors d’une connexion réussie, si les paramètres stockés sont obsolètes, rehachez le mot de passe soumis avec la nouvelle configuration et mettez l’enregistrement à jour.

Peppers : utiles, mais pas un substitut

Un pepper est une valeur secrète ajoutée au processus de hachage des mots de passe et stockée séparément de la base de données, souvent dans un gestionnaire de secrets ou un module de sécurité matériel.

Contrairement à un sel, un pepper doit rester secret.

Les peppers peuvent réduire les dommages si la base de données fuit mais pas les secrets de l’application. Ils sont surtout utiles dans des environnements matures avec une bonne gestion des clés. Ils sont moins utiles si le même attaquant peut voler à la fois la base de données et la configuration de l’application.

Si vous utilisez un pepper, planifiez soigneusement sa rotation. Le faire tourner peut obliger les utilisateurs à se reconnecter ou à réinitialiser leurs mots de passe, selon la conception. Un pepper est une couche supplémentaire, pas une raison d’affaiblir les réglages de hash sous-jacents.

La checklist opérationnelle

Si vous êtes responsable d’un système réel, la checklist pratique est courte :

• Stockez les mots de passe uniquement avec un algorithme standard de hachage de mots de passe.
• Utilisez un sel aléatoire unique par mot de passe.
• Préférez Argon2id pour les nouveaux développements.
• Ajustez les paramètres de coût sur du matériel proche de la production.
• Stockez l’algorithme et les paramètres avec chaque hash.
• Rehachez à la connexion lorsque les paramètres deviennent obsolètes.
• Ne journalisez jamais les mots de passe et ne les envoyez jamais à des outils d’analytics.
• Utilisez TLS partout où des identifiants sont soumis.
• Ajoutez MFA ou des passkeys lorsque le risque le justifie.
• Protégez les parcours de réinitialisation aussi sérieusement que les parcours de connexion.
• Ayez un plan d’incident pour les réinitialisations forcées et la notification des utilisateurs.

Le hachage des mots de passe n’a rien de glamour. C’est de la plomberie. Mais c’est le genre de plomberie qui détermine si une compromission devient un incident douloureux ou une catastrophe touchant tous les utilisateurs.

<!-- tool-cta:start -->

💡 Essayez ceci : Voyez comment la même entrée correspond à différents algorithmes avec le Hash Generator, qui rend concrète la différence entre les hachages rapides et ceux adaptés aux mots de passe.

<!-- tool-cta:end -->

Le modèle mental honnête

La meilleure façon de penser au hachage des mots de passe est la suivante :

Le hachage ne protège pas le mot de passe pendant que l’utilisateur le saisit. Il ne protège pas le compte après la connexion de l’utilisateur. Il ne protège pas les utilisateurs qui réutilisent des mots de passe sur le web.

Il protège le vérificateur stocké.

Cela semble étroit, mais c’est extrêmement important. Les bases de données fuient. Les sauvegardes fuient. Les systèmes de staging sont copiés. Des fournisseurs obtiennent des accès qu’ils ne devraient pas avoir. D’anciens exports restent dans du stockage objet plus longtemps que quiconque ne s’en souvient.

Lorsque cela arrive, la conception de votre stockage de mots de passe fait la différence entre des attaquants qui reçoivent des mots de passe et des attaquants qui reçoivent un problème de devinette coûteux.

Voilà ce que le hachage d’un mot de passe vous protège réellement contre.