Associez votre hachage de mots de passe à des mots de passe forts et aléatoires du générateur de mot de passe.
Pourquoi vous ne pouvez pas hacher des mots de passe avec SHA
SHA-256 et consorts sont conçus pour être rapides, et les attaquants adorent la rapidité : le matériel dédié peut tester des milliards de suppositions par seconde contre une base de hash fuitée.
Le hachage de mots de passe doit donc être délibérément coûteux. bcrypt et scrypt ajoutent tous deux un sel par utilisateur et un facteur de travail réglable pour que chaque supposition coûte du temps réel, de la mémoire, ou les deux.
Comment fonctionne bcrypt
bcrypt repose sur le programme de clés du chiffrement Blowfish. Un facteur de coût (2^cost itérations) contrôle le coût de chaque hash, et un sel de 128 bits est stocké avec le résultat.
Sa principale limite est un plafond d'entrée de 72 octets : les mots de passe plus longs sont tronqués sauf si la bibliothèque les pré-hache. Et comme il est limité par le CPU, les grappes GPU peuvent encore casser rapidement les hash bcrypt à faible coût.
En quoi scrypt diffère
scrypt est à dureté mémoire : il remplit un grand bloc de mémoire pendant la dérivation de la clé, donc un attaquant doit soit dépenser de grandes quantités de RAM par supposition, soit retomber sur un recalcul lent.
Les paramètres N (coût CPU/mémoire), r (taille de bloc) et p (parallélisation) règlent le compromis. La dureté mémoire donne à scrypt une meilleure résistance au craquage GPU et ASIC que bcrypt à réglages comparables.
bcrypt vs scrypt en un coup d'œil
| Propriété | bcrypt | scrypt |
|---|---|---|
| Type | Limité par CPU | À dureté mémoire |
| Limite d'entrée | 72 octets | Effectivement illimitée |
| Paramètres clés | cost (2^cost itérations) | N, r, p |
| Résistance GPU/ASIC | Modérée | Plus forte |
| Écosystème | Très largement disponible | Largement disponible, moins de valeurs par défaut |
Quoi utiliser en 2026
- Premier choix : Argon2id, le gagnant moderne à dureté mémoire avec résistance au matériel dédié
- Deuxième choix : scrypt quand Argon2 n'est pas disponible
- Héritage : bcrypt reste acceptable si vous utilisez cost ≥ 12 et pré-hachez les entrées de plus de 72 octets
- Utilisez toujours un sel aléatoire par utilisateur et ne créez jamais votre propre algorithme
Avertissement: N'ajoutez pas de secrets de type pepper, de double hachage ou d'itérations personnalisées « pour plus de sécurité » sans raison. La complexité invite aux bugs d'implémentation ; les algorithmes standard avec des paramètres sensés gagnent.
FAQ
Q.bcrypt est-il encore sûr en 2026 ?
A.Oui, avec un facteur de coût suffisant (≥ 12) et un sel par utilisateur. Il reste un choix raisonnable, mais Argon2id et scrypt offrent une meilleure résistance aux attaques GPU et ASIC pour les nouveaux systèmes.
Q.Quel facteur de coût dois-je utiliser ?
A.La valeur la plus élevée que vos utilisateurs tolèrent. Mesurez la latence de connexion : visez environ 100 à 300 ms sur votre matériel, puis ajoutez de la marge pour les futures montées en gamme CPU.
Q.Puis-je utiliser scrypt dans Node.js ?
A.Oui. Node.js fournit crypto.scrypt et crypto.scryptSync nativement, et la plupart des frameworks proposent des liaisons scrypt ou Argon2. Utilisez la variante asynchrone pour ne pas bloquer la boucle d'événements.
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
Commencez par un mot de passe fort
Mots de passe aléatoires avec règles personnalisées, générés dans votre navigateur.
Ordre de préférence
Choisissez Argon2id quand votre framework le fournit, scrypt sinon, et gardez bcrypt avec un coût d'au moins 12 pour la compatibilité héritée. Salez chaque mot de passe avec des octets aléatoires frais.
Commencez par une entrée forte : générez des mots de passe aléatoires localement avec le générateur de mot de passe.