Salt (cryptographie)
generalDéfinition
Un sel (salt) en cryptographie est une valeur aléatoire unique, générée pour chaque opération de hachage, qui est ajoutée à la donnée entrante (typiquement un mot de passe) avant le hachage. Le sel est stocké en clair à côté du hash résultant et n'a pas vocation à être secret — son rôle est de rendre chaque hash unique, même pour des données identiques. L'utilisation du sel résout un problème fondamental du hachage simple : sans sel, deux utilisateurs avec le même mot de passe ont le même hash en base de données. Un attaquant qui obtient la base de données peut identifier immédiatement les comptes aux mots de passe identiques, et les tables de correspondance pré-calculées (rainbow tables) permettent de retrouver instantanément les mots de passe courants. Avec un sel unique par utilisateur, même si Alice et Bob ont tous les deux le mot de passe "motdepasse123", leurs hashs seront complètement différents : H("sel_alice_aléatoire" + "motdepasse123") ≠ H("sel_bob_aléatoire" + "motdepasse123"). Les rainbow tables deviennent inutilisables car il faudrait en générer une pour chaque sel possible. Les exigences pour un sel cryptographiquement sûr incluent : généré aléatoirement via un CSPRNG (Cryptographically Secure Pseudo-Random Number Generator) comme /dev/urandom, os.urandom() ou crypto.randomBytes() ; longueur suffisante (128 bits minimum, 256 bits recommandés) ; unique par enregistrement — réutiliser un sel entre utilisateurs ou lors de changements de mot de passe annule partiellement la protection. En pratique, les fonctions de hachage de mots de passe modernes (bcrypt, Argon2, scrypt) gèrent automatiquement la génération et le stockage du sel dans leur format de sortie. bcrypt produit par exemple un hash de la forme $2b$12$[22 chars sel base64][31 chars hash base64] — le sel et le facteur de coût sont encodés directement dans la chaîne résultante, simplifiant considérablement la gestion. À ne pas confondre avec le pepper (poivre) : contrairement au sel, le poivre est une valeur secrète commune à tous les hashs, stockée séparément de la base de données (en variable d'environnement ou HSM), qui apporte une protection supplémentaire si la base de données est compromise sans que le fichier de configuration ne l'ait été.
Rainbow tables et défense par le sel
Les rainbow tables sont des tables de compromis temps-mémoire qui mappent des hashs pré-calculés à leurs textes clairs correspondants. Pour MD5 et SHA-1 sans sel, des tables couvrant l'intégralité des mots de passe courants (dictionnaires, combinaisons jusqu'à 8-10 caractères) sont disponibles en ligne gratuitement et permettent de retrouver instantanément la majorité des mots de passe. Le sel rend ces tables inutilisables en forçant le calcul d'une nouvelle table pour chaque sel — ce qui n'est pratiquement plus envisageable avec des sels de 128+ bits. Project RainbowCrack et les tables Ophcrack illustrent l'efficacité contre les systèmes sans sel.
Sel vs Pepper — couches complémentaires de sécurité
Le sel (stocké en clair avec le hash) et le poivre (secret partagé hors DB) sont des mécanismes complémentaires. Le sel protège contre les attaques sur la base de données isolée (dump SQL). Le poivre ajoute une protection si la base de données est compromise mais pas la configuration serveur. En combinant les deux : hash = Argon2(password + pepper, salt), un attaquant qui obtient la base de données ne peut pas calculer les hashs sans connaître le poivre. Cette approche est recommandée par l'OWASP Password Storage Cheat Sheet pour les applications traitant des données très sensibles.
Implémentation correcte du sel dans les frameworks
Les frameworks modernes gèrent automatiquement le sel. Django utilise PBKDF2_SHA256 avec sel aléatoire de 128 bits et 720 000 itérations par défaut (2024). Spring Security propose BCryptPasswordEncoder avec facteur de coût 10 par défaut. Laravel utilise bcrypt ou Argon2. Les développeurs ne doivent jamais implémenter manuellement la gestion des mots de passe : utiliser systématiquement les fonctions dédiées du framework ou des bibliothèques auditées (passlib en Python, password_hash/password_verify en PHP, bcryptjs en Node.js). L'OWASP recommande Argon2id comme premier choix en 2024.
Articles liés
Expert en cybersécurité offensive et intelligence artificielle. Pentest, audit et développement IA sur-mesure.
Services
- Audit Infrastructure
- Audit Kubernetes
- Audit Microsoft 365
- Audit Sécurité Réseau
- Analyse de Risques
- Audit Active Directory
- Audit Application Web
- Audit Cloud (AWS/Azure/GCP)
- Audit Messagerie
- Audit API (OWASP Top 10)
- Audit DevSecOps & CI/CD
- Audit Code Source (SAST)
- Audit Postes de Travail
- Audit Sauvegarde & Résilience
- Audit OT/SCADA (IEC 62443)
- Développement IA
- Formations
Ressources
Projets & Outils
© 2026 Ayi NEDJIMI Consultants. Tous droits réservés.
Un projet cybersécurité ?
Expert dispo · Réponse 24h