🧂 Le "Sel" en Cryptographie : Pourquoi vos mots de passe ne doivent pas être fades

1. Le problème : Le hachage déterministe

Par nature, un algorithme de hachage classique est déterministe. Cela signifie que pour une même entrée, vous aurez toujours la même sortie.

Exemple :

• Le mot de passe 123456 haché en MD5 donnera toujours e10adc3949ba59abbe56e057f20f883e.
• Si dix utilisateurs ont ce mot de passe, vous verrez dix fois la même chaîne dans votre base de données.

Le danger : Les Rainbow Tables Les pirates possèdent des dictionnaires géants (Rainbow Tables) contenant des milliards de correspondances entre "mots de passe connus" et "hashs". S'ils volent votre base, ils n'ont qu'à comparer leurs listes. Ils découvrent instantanément tous les mots de passe communs sans aucun effort de calcul.

2. La solution : Ajouter une pincée de sel

Le "sel" est une donnée aléatoire (une chaîne de caractères unique) que l'on génère pour chaque utilisateur et que l'on combine à son mot de passe avant de le hacher.

Analogie de la recette : Imaginez que le mot de passe est une base de gâteau.

• Sans sel : Tous les gâteaux au chocolat se ressemblent. Si vous en reconnaissez un, vous les connaissez tous.
• Avec sel : Avant de cuire chaque gâteau, on ajoute un ingrédient secret et différent pour chaque client (du piment, de la vanille, du sel...). Même si la base est la même (chocolat), le résultat final sera totalement différent.

3. Pourquoi ça protège mieux ?

1. Chaque hash devient unique : Même si 100 utilisateurs utilisent le mot de passe 123456, ils auront tous un sel différent. Leurs hashs stockés seront donc tous radicalement différents.
2. Inutilité des dictionnaires : Le pirate ne peut plus utiliser ses tables pré-calculées. Il est obligé de recalculer les combinaisons pour chaque sel de chaque utilisateur, un par un. Cela rend l'attaque des millions de fois plus lente et coûteuse.

4. Mais... comment vérifier le mot de passe plus tard ?

C'est la question que tout le monde se pose : "Si le sel est aléatoire et change pour chaque personne, comment faire pour le retrouver au moment où l'utilisateur tente de se connecter ?"

La règle d'or est simple : Le sel n'est pas un secret, c'est une empreinte. Il est donc stocké en clair avec le hash.

Comment ça se passe techniquement :

La plupart des standards modernes (Bcrypt, Argon2, Scrypt) concatènent tout dans une seule chaîne de caractères stockée en base de données : $algo$vitesse$SEL$HASH_FINAL

Le processus de vérification :

1. L'utilisateur tape son mot de passe.
2. Le système récupère le hash stocké en BDD.
3. Il en extrait la partie qui correspond au "Sel".
4. Il hache le mot de passe tapé par l'utilisateur en utilisant ce même sel.
5. Si le résultat final correspond au hash en BDD, l'accès est autorisé.

5. Les erreurs de débutant à éviter (Quel que soit votre langage)

❌ Erreur 1 : Utiliser le même sel pour tout le monde. Si vous utilisez un "sel global" (souvent appelé "Pepper" ou poivre, mais mal utilisé ici), vous ne réglez pas le problème des doublons. Un pirate qui découvre ce sel peut recréer une table de hachage spécifique pour votre site.

❌ Erreur 2 : Vouloir réinventer la roue. N'essayez jamais de fabriquer votre propre fonction de hachage à base de sha256(password + salt). Les bibliothèques standards de votre langage (BCrypt en Java/PHP/Node, Argon2 en Python/Go) gèrent la génération du sel, son stockage et la comparaison de manière sécurisée automatiquement.

🎓 Conclusion

Le sel transforme un système de sécurité poreux en un coffre-fort robuste. Il ne rend pas le mot de passe plus complexe, mais il rend le travail du pirate individuel au lieu de massif.

Retenez le slogan :

"Saler, c'est forcer le pirate à travailler un compte à la fois plutôt que tous en même temps."