Qu’est-ce que le salage en sécurité ? Explication du hachage des mots de passe

En juin 2012, un pirate a diffusé 117 millions d'enregistrements de comptes LinkedIn sur un forum russe. La liste était une succession de hachages SHA-1 non salés. L'algorithme SHA-1 est rapide. Sans sel pour différencier les mots de passe identiques, un même hachage se retrouvait des milliers de fois côte à côte. En environ 72 heures, des chercheurs en sécurité avaient déchiffré près de 90 % du fichier. Lorsque cette faille a refait surface en mai 2016, intégrée à un ensemble de données de 167 millions d'enregistrements, ces identifiants ont alimenté des campagnes de bourrage d'identifiants pendant des années.

La solution qui aurait permis de minimiser l'impact de cette faille – l'ajout de sel à chaque mot de passe stocké – existait déjà en 1979. Il s'agit du salage. Cette technique n'est ni nouvelle, ni coûteuse, ni particulièrement ingénieuse. Elle fait toute la différence entre une fuite de données circonscrite et un problème de mots de passe généralisé pendant cinq ans.

La plupart des failles de sécurité modernes dans le stockage des mots de passe proviennent toujours de la même cause : on a jugé que l’utilisation de SHA-256 était suffisante. Cet article explique en détail ce qu’est le salage, comment il fonctionne en pratique, contre quoi il protège et ce qu’il ne protège pas, et quelle valeur par défaut l’OWASP recommande pour 2026 mots de passe.

Qu’est-ce que le salage en sécurité et en hachage de mots de passe ?

En résumé, le salage consiste à ajouter des données aléatoires à un mot de passe avant son hachage. Cette valeur aléatoire, appelée sel, est générée une seule fois par compte, simultanément au hachage du mot de passe. Elle est stockée en clair à côté du hachage obtenu et relue à chaque connexion. Il ne s'agit ni d'une clé, ni d'un secret, ni d'un chiffrement. C'est un modificateur public dont la seule fonction est de garantir que deux utilisateurs ayant le même mot de passe ne partagent jamais le même hachage.

Le hachage seul est à sens unique. En appliquant SHA-256 ou Argon2id à un mot de passe, on obtient une valeur de longueur fixe qu'aucun algorithme ne peut inverser. Le problème, c'est que cette absence d'algorithme exclut une solution de facilité : la recherche du hachage dans un dictionnaire précalculé. Le salage bloque cette possibilité. L'ajout d'un sel au processus de hachage génère un hachage unique pour chaque utilisateur, même si leurs mots de passe sont identiques. Ainsi, des mots de passe courants comme « password » et « qwerty » ne se retrouvent plus en conflit dans la base de données. Le salage garantit que la fuite d'une seule entrée ne révèle rien à l'attaquant sur les autres utilisateurs.

Trois règles distinguent un sel utilisable d'un sel inutile. Première règle : chaque mot de passe possède son propre sel aléatoire, généré à chaque inscription ou réinitialisation de compte. Un mot de passe salé réutilisé pour plusieurs comptes n'est guère plus sûr qu'un mot de passe non salé : une attaque par force brute fonctionne de la même manière. Deuxième règle : le sel peut être public. Connaître le sel seul ne donne aucun avantage à un attaquant pour accéder à la fonction de hachage sous-jacente. Le sel est donc stocké dans la base de données, à côté de la fonction de hachage, et cet emplacement est tout à fait acceptable, voire recommandé. Troisième règle : les valeurs du sel proviennent d'un générateur de nombres pseudo-aléatoires cryptographiquement sécurisé. Linux en propose un via `getrandom(2)`. Node.js l'appelle `crypto.randomBytes`. La bibliothèque standard de Python l'encapsule dans `secrets.token_bytes`. La fonction non cryptographique `Math.random()` est inadaptée, même si elle apparaît bien plus souvent qu'elle ne le devrait dans du code audité.

Deux personnes choisissant « hunter2 » comme mot de passe devraient obtenir deux hachages stockés totalement différents. C'est le salage qui permet cela. Sans sel, la base de données divulgue non seulement les hachages, mais aussi le réseau social des utilisateurs partageant leurs mots de passe.

Comment fonctionne le salage des mots de passe ?

Le mécanisme se décompose en quatre étapes, et dix années de violations de données relatives au stockage des mots de passe montrent que presque tous les échecs surviennent parce que quelqu'un a négligé l'une d'entre elles.

La première étape s'exécute lors de l'inscription. L'application demande à un générateur de nombres pseudo-aléatoires cryptographiquement sécurisé (CSPRNG) de seize à trente-deux octets aléatoires. Il s'agit du sel. Les recommandations OWASP 2025 considèrent seize octets (128 bits) comme le minimum ; auth0 et plusieurs fournisseurs de gestionnaires de mots de passe recommandent trente-deux octets. La publication spéciale 800-63B-4 du NIST fixe un minimum de quatre octets, mais avertit que des collisions liées à la date d'anniversaire commencent à apparaître aux alentours de soixante-cinq mille utilisateurs avec cette taille, ce qui explique pourquoi personne n'utilise réellement quatre octets.

La deuxième étape consiste à combiner le sel avec le mot de passe choisi par l'utilisateur. La concaténation est la méthode la plus courante : le sel est alors placé avant ou après le mot de passe. Certains systèmes utilisent plutôt HMAC, en considérant le sel comme la clé HMAC, ce qui permet de contourner certains problèmes d'extension de longueur liés à la concaténation brute.

La troisième étape consiste à appliquer un algorithme de hachage de mot de passe aux données d'entrée combinées — ce que les manuels de cryptographie appellent une fonction de dérivation de clé (KDF). C'est à cette étape que la plupart des équipes échouaient, souvent en optant pour un algorithme de hachage générique et en pensant que le travail était terminé. Le SHA-256 simple est inadapté au stockage des mots de passe. Un GPU grand public en 2026 effectue plus de cent milliards de hachages SHA-256 par seconde ; ainsi, même avec un sel, le coût par tentative de hachage cryptographique reste négligeable. Le salage neutralise les attaques par tables arc-en-ciel. Il ne ralentit pas, à lui seul, le craquage de mots de passe par force brute. L'outil approprié est une fonction volontairement lente et gourmande en mémoire : Argon2id est la valeur par défaut recommandée par l'OWASP, scrypt et bcrypt étant acceptables, et PBKDF2 avec un nombre d'itérations très élevé autorisé lorsque la conformité à la norme FIPS-140 l'impose.

L'étape quatre consiste à stocker le hachage et le sel. Les bibliothèques modernes gèrent le format de stockage, vous évitant ainsi de gérer manuellement le sel. Un résultat bcrypt ressemble à `$2b$12$9f4c8a7b...kQR8YZpL9` : cette chaîne unique contient l'identifiant de l'algorithme, le facteur de coût, le sel et la valeur de hachage. Argon2id utilise le format de chaîne PHC analogue : `$argon2id$v=19$m=19456,t=2,p=1$$`. Il vous suffit d'écrire cette chaîne dans une colonne de la base de données et le tour est joué. La bibliothèque s'est chargée de tout le nécessaire pour stocker les mots de passe en toute sécurité : génération de données aléatoires pour le sel, hachage du mot de passe avec un algorithme lent et regroupement du résultat pour sa récupération.

La connexion suit le même processus en sens inverse. L'application recherche le sel et le hachage stocké de l'utilisateur, applique le même algorithme au mot de passe saisi avec le même sel, puis compare le résultat au hachage stocké en utilisant une comparaison à temps constant. Le temps constant est crucial : une simple comparaison avec l'opérateur `==` divulgue des informations sur le nombre d'octets correspondants, ce qui a engendré de véritables vulnérabilités d'attaques temporelles. Utilisez `hmac.compare_digest`, `crypto.timingSafeEqual` ou l'équivalent de votre framework.

Pourquoi le salage est important : le problème de la table arc-en-ciel

Les tables arc-en-ciel constituent le type d'attaque que le salage a été inventé pour contrer. Imaginez une table de correspondance précalculée qui associe chaque mot de passe plausible (chaque mot du dictionnaire, chaque variante courante, chaque entrée de liste divulguée) à son hachage SHA-256. Ces tables existent, elles sont vendues sur les forums de piratage et leur taille se compte en téraoctets. Une fois qu'un attaquant possède une base de données contenant des hachages non salés, la recherche d'un hachage dans une table arc-en-ciel se résume à une simple requête de base de données, et non à une opération de piratage. Le piratage de LinkedIn en 2012 s'est déroulé exactement de cette manière : 117 millions de hachages SHA-1 non salés ont été comparés à une table arc-en-ciel, dont 90 % ont été déchiffrés en trois jours environ.

L'ajout d'un sel par utilisateur rend les tables arc-en-ciel inopérantes. L'attaquant aurait besoin d'une table précalculée distincte pour chaque valeur de sel unique. Avec un sel aléatoire de seize octets, cela représenterait 117 millions de tables différentes pour 117 millions d'utilisateurs, et chaque table pèserait encore plusieurs téraoctets. Le coût du stockage à lui seul rend cette solution irréalisable. L'attaque est donc invalidée.

C'est précisément le rôle du sel. Son utilisation est volontairement ciblée. Le salage ne ralentit pas une attaque par force brute déterminée contre un utilisateur spécifique. Il n'empêche pas le bourrage d'identifiants suite à une fuite antérieure. Enfin, le salage est inutile si le mot de passe est « 123456 » : l'attaquant teste le dictionnaire de mots de passe le plus évident, et le sel est recalculé à chaque tentative sans que cela n'affecte significativement le coût de chaque tentative.

Le salage permet d'atténuer efficacement les attaques par tables arc-en-ciel et la fuite d'informations sur la réutilisation des mots de passe entre utilisateurs d'une même base de données. Le hachage lent atténue le coût par tentative. Le poivre atténue le vol d'informations limité à la base de données. L'authentification multifacteur (MFA) atténue le bourrage d'identifiants. Le salage constitue une couche de sécurité parmi d'autres : ajouter un sel pour rendre les mots de passe plus difficiles à deviner ne revient pas à rendre chaque mot de passe individuellement difficile à deviner. L'objectif du salage est de fournir un hachage différent pour chaque utilisateur ; rendre chaque tentative coûteuse est un problème distinct.

Hachage vs chiffrement vs salage

Trois termes souvent confondus, notamment dans les écrits de non-spécialistes. Ils ne sont pas interchangeables.

Le chiffrement protège les données que vous souhaitez récupérer ultérieurement. Le destinataire possède la clé, l'applique et lit l'original. Le hachage est irréversible : une fois qu'un mot de passe est transformé en hachage, aucun algorithme ne peut le déchiffrer. Le salage est un modificateur appliqué à l'entrée d'une fonction de hachage ; il n'a aucune signification en soi.

La faille de sécurité d'Adobe en 2013 est un exemple édifiant. Adobe stockait 153 millions d'enregistrements d'utilisateurs en chiffrant les mots de passe avec 3DES en mode ECB, à l'aide d'une seule clé pour l'ensemble du site. Ce choix s'est avéré catastrophique. Le chiffrement est une méthode inadaptée au stockage des mots de passe. Le mode ECB expose les entrées et sorties identiques. Réutiliser une seule clé pour toute la base de données signifiait que son décryptage permettait de décrypter les 153 millions d'enregistrements. Schneier l'a qualifiée de l'une des pires violations de mots de passe de l'histoire. La solution, à tous les niveaux, a consisté à adopter un hachage lent et salé.

Sel contre poivre : la défense à deux couches

Le poivre est un cousin moins connu du sel. Le principe : une valeur secrète supplémentaire, appliquée à chaque mot de passe traité par l’application, mais stockée hors de la base de données. Il peut s’agir d’une variable d’environnement, d’une entrée du service de gestion des clés ou d’une clé résidente du module de sécurité matériel (HSM). Le sel est stocké en clair à côté du hachage, contrairement au poivre.

Le modèle de menace repose sur le vol de la base de données uniquement. Si un attaquant ne vole que la base de données (par injection SQL, sauvegarde mal configurée ou fuite de données), il dispose des clés de hachage, mais pas du secret global. Sans ce secret, il ne peut même pas commencer une attaque par force brute, car chaque tentative de hachage est incomplète, car il lui manque le modificateur secret global.

Une implémentation classique exécute `argon2id(salt + password + pepper)` ou, plus rigoureusement, calcule d'abord `HMAC(pepper, password + salt)` et fournit le résultat à Argon2id. L'OWASP recommande l'utilisation de pepper pour les systèmes critiques, tout en reconnaissant les inconvénients : la rotation du pepper est complexe à mettre en œuvre. Elle implique de rehacher le mot de passe de chaque utilisateur à chaque connexion, et si le pepper est perdu sans sauvegarde, tous les comptes deviennent inaccessibles. La plupart des applications grand public se passent de pepper. Les banques, les administrations et les établissements de santé, en revanche, l'utilisent généralement.

Le hachage moderne des mots de passe en 2026

Les recommandations 2025 de l'OWASP concernant le stockage des mots de passe classent quatre algorithmes par ordre de préférence. Le sel est intégré à tous ; vous n'avez pas besoin de le générer manuellement.

Argon2id est gourmand en mémoire : chaque tentative de hachage consomme non seulement des cycles CPU, mais aussi une quantité définie de RAM. Le minimum OWASP de 19 Mio par hachage implique qu'un attaquant concevant un ASIC personnalisé doit également prévoir une grande quantité de mémoire rapide, or la mémoire représente le coût le plus élevé de toute machine. La variante « id » combine Argon2i (résistant aux attaques par canaux auxiliaires) et Argon2d (résistant au GPU) en exécutant Argon2i pour la première moitié du processus et Argon2d pour la seconde.

Scrypt est antérieur à Argon2id et repose sur le même principe de forte consommation de mémoire. Bcrypt est encore plus ancien, plus simple, et sa limite stricte de 72 octets en entrée peut parfois poser problème aux applications utilisant de longues phrases de passe ; il est donc recommandé de pré-hacher avec SHA-256 et d'encoder en base64 si nécessaire. PBKDF2 est l'option la plus lente, mais conforme à la norme FIPS ; l'OWASP a porté le nombre d'itérations de SHA-256 à 600 000 en 2023, contre 310 000 auparavant.

Sont exclus de cette liste : les algorithmes SHA-256 et SHA-512 simples, MD5, SHA-1 et toute fonction personnalisée se terminant par « + sel ». La vitesse est un critère éliminatoire. SHA-256 a été conçu pour être rapide sur du matériel standard, ce qui est à l’opposé des exigences du stockage des mots de passe.

Erreurs de salage courantes constatées lors d'audits réels

Les rapports de violations de données dans le monde réel signalent sans cesse les mêmes erreurs.

Réutiliser le même sel pour chaque utilisateur compromet tout le mécanisme : le problème de la table arc-en-ciel réapparaît, avec une étape supplémentaire. Utiliser le nom d'utilisateur comme sel est pire, car les noms d'utilisateur se répètent d'un système à l'autre et les tables arc-en-ciel peuvent être précalculées pour les plus courants. Avec des sels de moins de seize octets, des collisions commencent à se produire pour les grandes bases d'utilisateurs. Générer un sel avec une fonction aléatoire non cryptographique — `Math.random()`, `time(0)` mod quelque chose, le générateur de nombres aléatoires par défaut du langage — produit des valeurs prévisibles qui rendent le salage inefficace.

Une erreur plus subtile consiste à stocker le sel sur un serveur différent « pour des raisons de sécurité ». Le sel n'est pas un secret. Le répartir sur plusieurs systèmes complexifie les opérations sans renforcer la sécurité cryptographique. Stockez-le sur la même ligne que le hachage. Les chaînes PHC modernes le font automatiquement.

La principale faille, constatée lors des audits de 2026, concerne le hachage avec SHA-256 simple, un sel et l'expédition. Le sel empêche l'utilisation de tables arc-en-ciel, mais il est inefficace contre une ferme de GPU effectuant dix milliards de tentatives par seconde sur un seul compte. La solution ne consiste pas à ajouter un second sel, mais à opter pour une KDF lente comme Argon2id.

Dernière étape : les anciens hachages non salés. La migration est obligatoire. La procédure standard consiste à vérifier l’ancien hachage lors de la prochaine connexion, à le recalculer avec l’algorithme moderne, puis à l’écraser. Pour les utilisateurs qui ne se connectent plus jamais, une réinitialisation du mot de passe est obligatoire à intervalles réguliers.

Pourquoi le salage seul ne suffit pas

Le salage est une protection, pas une forteresse. Il neutralise une attaque spécifique — les tables précalculées — et ne révèle rien sur la robustesse du mot de passe sous-jacent. Les attaques par force brute restent efficaces contre les mots de passe faibles. Le bourrage d'identifiants fonctionne toujours contre les mots de passe réutilisés. L'hameçonnage fonctionne toujours contre n'importe quel mot de passe.

En 2026, la véritable sécurité des mots de passe repose sur quatre défenses. Argon2id, avec un sel de seize octets par utilisateur, assure le stockage. Un chiffrement Pepper, optionnel mais fortement recommandé pour les systèmes sensibles, bloque le vol d'informations d'identification uniquement au niveau de la base de données. L'authentification multifacteur empêche le bourrage d'identifiants et la plupart des tentatives d'hameçonnage. Une surveillance continue des violations de données – assurée par des services comme Have I Been Pwned et son API – détecte dès qu'un identifiant utilisateur apparaît dans une fuite afin de contraindre ce dernier à le réinitialiser.

Si l'on néglige l'une de ces couches de protection, un attaquant finit par trouver la faille. Le salage seul, ou toute autre défense prise isolément, constitue précisément le point faible identifié par toutes les analyses post-incident de ces dix dernières années.

Jordan Morris

Jordan Morris is an AI expert with over a decade of experience and the author of a widely-read blog focused on artificial intelligence. His content spans a range of topics—from the ethics of machine learning to real-world applications of neural networks in business. Known for his clear writing and deep insights, Jordan has become a trusted voice in the AI community, appealing to both newcomers and seasoned professionals alike.