Construisez des systèmes de mots de passe sécurisés avec nos outils de mot de passe. Apprenez les bonnes pratiques de hachage et de chiffrement.
Chiffrement par mot de passe : ce que c'est et quand l'utiliser
Le chiffrement par mot de passe dérive une clé à partir d'un mot de passe, puis chiffre les données avec cette clé : le mot de passe suffit pour retrouver le texte clair. C'est l'inverse du hachage, qui est à sens unique et prouve seulement qu'une valeur correspond.
La règle est simple. Si vous devez relire les données plus tard — une sauvegarde, un export, un fichier transmis à quelqu'un — utilisez un chiffrement par mot de passe avec une vraie dérivation de clé (PBKDF2, Argon2 ou scrypt) et un chiffrement authentifié comme AES-256-GCM. Si vous devez seulement vérifier une connexion, utilisez un hachage de mot de passe comme bcrypt, et jamais un chiffrement.
La violation de base de données
C'est lundi matin. Vous sirotez un café quand l'alerte de sécurité arrive dans votre boîte mail. Votre base de données utilisateurs a fuité. Des millions de mots de passe exposés.
Mais voici le rebondissement : l'attaquant n'a obtenu que des hachages, pas les mots de passe en clair. Et vous avez utilisé bcrypt avec un sel approprié. Ces mots de passe sont toujours sûrs.
C'est la différence entre un bon et un mauvais stockage de mots de passe. Explorons comment bien faire.
Hachage vs chiffrement : différence critique
Les mots de passe ne doivent jamais être chiffrés. Ils doivent être hachés. Voici pourquoi :
Le chiffrement est réversible. Si quelqu'un obtient la clé, il peut déchiffrer tous les mots de passe. Le hachage est à sens unique. On ne peut pas déhacher un mot de passe.
Lorsqu'un utilisateur se connecte, vous hachez sa saisie et la comparez au hachage stocké. S'ils correspondent, le mot de passe est correct. Vous n'avez jamais besoin de connaître le mot de passe réel.
Choisir le bon algorithme
Tous les algorithmes de hachage ne conviennent pas aux mots de passe. Voici quoi utiliser et quoi éviter :
- Utilisez bcrypt – Norme industrielle, facteur de coût adaptatif, sel intégré
- Utilisez Argon2 – Gagnant du concours de hachage de mots de passe, à dureté mémoire
- Utilisez scrypt – À dureté mémoire, bon pour les cryptomonnaies
- N'utilisez jamais MD5 – Cassé, trop rapide, vulnérable aux tables arc-en-ciel
- N'utilisez jamais SHA-256 – Conçu pour la vitesse, mauvais pour les mots de passe
- N'utilisez jamais le texte en clair – Inacceptable en toutes circonstances
Comprendre bcrypt
Bcrypt est l'algorithme de hachage de mots de passe le plus largement recommandé. Il possède plusieurs caractéristiques clés qui le rendent idéal pour les mots de passe.
D'abord, il est lent. Bcrypt inclut un facteur de coût (facteur de travail) qui rend le hachage intentionnellement lent. Cela empêche les attaques par force brute. Un facteur de coût de 10-12 est recommandé pour la plupart des applications.
Ensuite, il gère automatiquement le sel. Le sel est une donnée aléatoire ajoutée à chaque mot de passe avant le hachage. Cela empêche les attaques par tables arc-en-ciel. Bcrypt génère et stocke le sel automatiquement.
Guide d'implémentation
Voici comment implémenter le hachage de mots de passe dans différents langages :
Node.js (bcrypt)
const bcrypt = require('bcrypt'); const saltRounds = 12; // Hash password const hash = await bcrypt.hash(password, saltRounds); // Verify password const match = await bcrypt.compare(password, hash);
Python (bcrypt)
import bcrypt # Hash password password = b'super secret password' salt = bcrypt.gensalt(rounds=12) hashed = bcrypt.hashpw(password, salt) # Verify password if bcrypt.checkpw(password, hashed): print('Match')
Erreurs courantes de stockage de mots de passe
Même les développeurs expérimentés commettent ces erreurs :
- Utiliser des algorithmes de hachage rapides – SHA-256, MD5 sont conçus pour la vitesse, facilitant la force brute
- Ne pas utiliser de sel – Sans sel, des mots de passe identiques produisent des hachages identiques
- Coder le sel en dur – Le sel doit être unique par mot de passe et généré aléatoirement
- Facteur de coût insuffisant – Trop bas et le hachage est trop rapide ; trop haut et les performances souffrent
- Stocker les mots de passe dans les journaux – Ne journalisez jamais les mots de passe, même pour le débogage
FAQ
Q.Qu'est-ce que le pepper ?
A.Le pepper est une clé secrète ajoutée à tous les mots de passe avant le hachage, contrairement au sel qui est unique par mot de passe. Il offre une sécurité supplémentaire si la base de données fuite mais que la clé de pepper reste sûre.
Q.Comment migrer vers un meilleur algorithme ?
A.Rehachez les mots de passe à la prochaine connexion. Lorsqu'un utilisateur se connecte avec l'ancien hachage, vérifiez-le, puis rehachez avec le nouvel algorithme et stockez le nouveau hachage.
Q.La longueur du mot de passe compte-t-elle avec le hachage ?
A.Oui. Bcrypt tronque les mots de passe à 72 octets. Encouragez les utilisateurs à utiliser des mots de passe longs, mais envisagez de pré-hacher les très longs mots de passe si nécessaire.
Q.Comment chiffrer des fichiers protégés par mot de passe dans le navigateur ?
A.Dérivez une clé de 256 bits à partir de la phrase secrète avec PBKDF2, chiffrez avec AES-256-GCM, puis stockez le sel et l'IV à côté du texte chiffré : rien à installer, rien à envoyer. Le chiffreur AES-256-GCM applique exactement ces étapes avec l'API Web Crypto.
Q.Un mot de passe chiffré est-il un hachage ou du texte chiffré ?
A.Les deux existent en base et signifient l'inverse. Une chaîne comme `$2b$12$...` est un hachage bcrypt : 60 caractères, non réversible, utile uniquement pour vérifier une connexion. Le texte chiffré avec sel et IV est du chiffrement : réversible avec le mot de passe. Si un service peut vous montrer votre mot de passe d'origine, il ne le hache pas.
Q.Le chiffrement par mot de passe est-il identique au hachage ?
A.Non. Le chiffrement par mot de passe est réversible : le mot de passe dérive une clé et permet de déchiffrer. Le hachage est à sens unique : il permet seulement de vérifier. Utilisez le chiffrement pour les données que vous devez récupérer (sauvegardes, exports, messages) et le hachage pour les identifiants que vous devez uniquement comparer.
Références
- Aide-mémoire OWASP sur le stockage des mots de passe : https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html
- NIST SP 800-63B – Digital Identity Guidelines : Authentification : https://pages.nist.gov/800-63-3/sp800-63b.html
Chiffrez vos données localement
Chiffrez du texte ou des fichiers avec AES-256-GCM dans votre navigateur — sans envoi, sans compte.
Conclusion
Le chiffrement par mot de passe ne vaut que ce que vaut la dérivation de clé qui l'entoure. Construisez votre flux avec le chiffreur AES-256-GCM.
Articles liés
Chiffrement AES en production
La différence entre théorie et pratique est immense. Voici ce qui tourne mal dans les applications réelles.
API Web Crypto : guide pour développeurs
L'API Web Crypto chiffre, hache et signe nativement dans le navigateur : generateKey, encrypt, decrypt, hash et sign. Ce que l'API couvre, et quand une bibliothèque JavaScript reste utile.
Déchiffrer AES-256-GCM localement
Déchiffrer AES-256-GCM est simple lorsque vous disposez du mot de passe et des bonnes métadonnées. Voici la procédure exacte – et les erreurs qui font échouer le déchiffrement.
bcrypt vs Argon2 : choisir un hachage
bcrypt protège les mots de passe depuis des décennies ; Argon2 est la recommandation moderne, résistante à la mémoire. Voici la comparaison et quand utiliser chacun en 2026.
Impression de QR codes : bonnes pratiques
Un QR code qui ne se scanne pas sur papier est un lien cassé. Réglez la taille minimale, le contraste, la correction d'erreur et la zone de silence avant d'envoyer le fichier à l'impression.
Outils de sécurité : zéro connaissance
Les outils auxquels vous vous adressez avec des données sensibles ne devraient pas voir ces données. Un guide de la boîte à outils de sécurité zéro connaissance : ce que fait chaque outil, quand l'utiliser et comment le vérifier.