Le hachage des mots de passe est essentiel pour la sécurité des utilisateurs. Découvrez pourquoi le stockage en clair est dangereux, le rôle du sel, et les meilleurs algorithmes à privilégier pour protéger vos comptes contre les attaques.
Le hachage des mots de passe est une méthode essentielle pour protéger les données sensibles des utilisateurs sur les sites web. Bien qu'un mot de passe semble être une simple chaîne de texte, il représente une information particulièrement vulnérable. Si un service stocke les mots de passe en clair, n'importe quelle fuite de la base de données livre immédiatement des accès prêts à l'emploi aux attaquants. C'est pourquoi les sites modernes utilisent le hachage : une technique qui permet de ne jamais conserver le mot de passe original, mais seulement sa représentation numérique irréversible.
Le hachage des mots de passe consiste à transformer le mot de passe initial en une chaîne de longueur fixe à l'aide d'une fonction de hachage spécifique. Par exemple, un mot de passe comme PixelBurn2026! sera converti en une valeur totalement différente, impossible à relier directement au texte d'origine.
La fonction de hachage opère de façon unidirectionnelle : il est facile d'obtenir un haché à partir d'un mot de passe, mais il est impossible de retrouver le mot de passe à partir du haché. C'est la différence principale avec le chiffrement, qui peut être inversé à l'aide d'une clé. Le hachage, lui, n'a pas de clé pour le déchiffrer.
Un point essentiel du hachage est sa prévisibilité : un même mot de passe, dans les mêmes conditions, produira toujours le même haché. Cela permet au site de vérifier un mot de passe sans jamais stocker sa version originale.
En revanche, la moindre modification dans le mot de passe change radicalement le résultat. Par exemple, Password123 et Password124 produiront des hachés totalement différents, même s'ils ne diffèrent que d'un caractère. Impossible donc de deviner la similarité des mots de passe d'origine en observant leurs hachés.
Attention : le haché lui-même n'est pas absolument sûr. Un attaquant n'a pas besoin de " décrypter " le haché : il peut simplement tester différentes combinaisons de mots de passe, calculer leur haché et comparer avec la valeur volée. Si ça correspond, le mot de passe d'origine est découvert. La sécurité dépend donc de l'algorithme utilisé, de la présence de sel, et des paramètres de difficulté du hachage.
Lors de la création d'un compte, le site ne doit jamais enregistrer le mot de passe en clair dans sa base de données. Le serveur applique plutôt un algorithme de hachage et ne sauvegarde que le résultat obtenu, accompagné de paramètres nécessaires à la vérification future.
À chaque connexion, l'utilisateur saisit son mot de passe, le serveur lui applique le même algorithme, puis compare le nouveau résultat avec la valeur stockée. Si ça correspond, l'accès est accordé.
Un service bien conçu n'a donc jamais besoin de connaître le mot de passe d'origine après l'inscription. Il ne manipule que le résultat du hachage. Pour cette raison, un site sérieux ne pourra jamais afficher votre ancien mot de passe à la demande.
En cas d'oubli, les services sécurisés ne renvoient jamais le mot de passe initial. Ils proposent plutôt une procédure de réinitialisation : l'utilisateur prouve son identité, définit un nouveau mot de passe, qui sera alors haché et stocké à la place de l'ancien.
Cette méthode est cruciale en cas de fuite de base de données. Si des mots de passe en clair sont présents, l'attaquant obtient immédiatement des accès. Si seuls des hachés robustes sont conservés, il devra les casser un par un, ce qui peut être extrêmement coûteux en ressources, selon l'algorithme et les paramètres utilisés.
Si un site conserve les mots de passe en texte lisible, toute fuite de données compromet directement les comptes concernés. L'attaquant n'a besoin d'aucun effort : il récupère instantanément les couples identifiant/mot de passe valides.
Le problème s'aggrave avec la réutilisation des mots de passe. Beaucoup d'utilisateurs utilisent la même combinaison sur plusieurs plateformes : forum, messagerie, boutique en ligne, etc. Une fuite sur un site permet alors à l'attaquant de tester les identifiants dérobés ailleurs et de pirater plusieurs comptes d'un coup.
Pour en savoir plus sur les mesures à prendre après ce type d'incident, consultez notre guide : Comment vérifier une fuite de données et protéger vos mots de passe en 2025.
Un simple hachage ne suffit pas toujours, surtout si l'algorithme utilisé est trop rapide. Par exemple, SHA-256 est idéal pour vérifier l'intégrité des fichiers, mais inadapté pour la sécurité des mots de passe : des cartes graphiques modernes peuvent calculer des millions de hachés SHA-256 en un clin d'œil, rendant le cassage par force brute efficace contre les mots de passe simples.
L'attaquant ne cherche généralement pas à inverser mathématiquement la fonction de hachage. Il utilise plutôt des listes de mots de passe courants, des combinaisons de mots, de dates et de symboles, en calcule les hachés et les compare à ceux de la base volée. Plus l'algorithme est rapide, plus il peut tester de variantes à la seconde.
C'est pourquoi la sécurité des mots de passe repose sur plusieurs couches : outre le hachage, on utilise une valeur de sel unique et des algorithmes conçus pour consommer volontairement beaucoup de ressources, ralentissant ainsi le cassage massif.
Même un bon algorithme de hachage devient vulnérable si des mots de passe identiques produisent toujours le même résultat. Deux utilisateurs ayant choisi le même mot de passe auront un haché identique, ce qui facilite l'analyse de la base volée et accélère le repérage des mots de passe populaires.
Pour contrer cela, on utilise un sel : une valeur aléatoire ajoutée au mot de passe avant le hachage. Chaque utilisateur se voit attribuer son propre sel unique, ce qui rend chaque haché différent, même pour des mots de passe identiques.
Par exemple, deux utilisateurs choisissent " qwerty123 ". Avec des sels différents, leurs hachés seront totalement distincts. L'attaquant ne peut plus calculer une fois le haché d'un mot de passe courant et retrouver tous les utilisateurs concernés en un seul coup.
Le sel protège également contre les bases de données de hachés pré-calculés, appelées rainbow tables. Sans sel, un attaquant peut préparer à l'avance des millions de hachés de mots de passe courants et trouver rapidement des correspondances. Avec un sel unique par utilisateur, il doit recommencer l'opération pour chaque cas.
Le sel n'a pas besoin d'être secret : il est généralement stocké en clair dans la base, à côté du haché, car le serveur en a besoin lors de la vérification. Sa tâche est de garantir l'unicité de chaque haché, pas d'être une information confidentielle.
Attention : le sel ne protège pas un mot de passe faible contre les attaques par force brute. Si l'utilisateur choisit une combinaison trop simple, l'attaquant pourra toujours la tester. Il faut donc combiner le sel avec un algorithme de hachage spécialisé, qui rend chaque tentative coûteuse en temps et en ressources.
Pour les mots de passe, il ne suffit pas de choisir n'importe quelle fonction de hachage cryptographique. Des algorithmes comme SHA-256 ou SHA-512 sont conçus pour être rapides, ce qui est utile pour la vérification de fichiers mais problématique pour la sécurité des mots de passe : plus le hachage est rapide, plus un attaquant peut tester de variantes par seconde.
C'est pourquoi on privilégie des solutions spécialisées, volontairement lentes. Bcrypt est l'une des plus connues. Il permet de régler la complexité du calcul (paramètre cost) : plus la valeur est élevée, plus le calcul d'un haché prend du temps. Pour un utilisateur, la différence est imperceptible, mais pour un attaquant qui veut tester des millions de mots de passe, le ralentissement est significatif.
Plus récemment, Argon2 s'est imposé comme référence. Cet algorithme limite l'attaquant à la fois en temps de calcul et en mémoire nécessaire, ce qui est crucial contre les attaques sur GPU ou matériels spécialisés capables de paralléliser des calculs simples à grande échelle. Pour les mots de passe, la variante Argon2id est généralement recommandée, combinant plusieurs avantages de sécurité.
Comparer bcrypt à Argon2 n'a pas de sens en termes d'obsolescence : bcrypt reste une solution robuste s'il est bien paramétré. Toutefois, pour les nouveaux projets, Argon2id est souvent préféré pour sa flexibilité et sa résistance accrue face aux évolutions matérielles.
La sécurité dépend aussi des paramètres choisis. Une complexité trop faible rendra même l'algorithme le plus moderne facile à casser. Les paramètres doivent donc être adaptés régulièrement à la puissance des ordinateurs, pour maintenir l'équilibre entre confort utilisateur et coût de l'attaque.
Parallèlement, de nouvelles méthodes de connexion émergent, où l'utilisateur n'a même plus besoin d'envoyer un mot de passe classique au serveur. Pour en savoir plus, découvrez notre dossier sur l'authentification sans mot de passe : Passkeys, FIDO2 et WebAuthn.
Le hachage des mots de passe permet à un site de vérifier l'authenticité des données sans jamais stocker le mot de passe en clair. Seul le haché est conservé, et lors de la connexion, le serveur le recalcule à partir de la saisie de l'utilisateur pour comparer les résultats.
Une stratégie de stockage fiable ne s'arrête pas à la fonction de hachage : l'ajout d'un sel unique protège contre la détection des mots de passe identiques, et l'emploi d'algorithmes spécialisés comme bcrypt ou Argon2id rend le cassage de masse considérablement plus coûteux.
Si un service stocke les mots de passe en texte lisible, ou utilise un algorithme trop rapide sans sel, une seule fuite peut compromettre des milliers de comptes. Le principe de base d'une sécurité moderne est donc simple : le mot de passe d'un utilisateur ne doit jamais être enregistré sous une forme lisible ou récupérable.