Bcrypt reste la référence pour le stockage sûr des mots de passe. Son mécanisme de salage unique et son facteur de coût rendent les attaques par tables arc-en-ciel pratiquement inutiles.
Cet article explique pourquoi la dépendance au bon algorithme de hachage influe directement sur la sécurité. Il propose des mises en œuvre concrètes et des retours pratiques.
A retenir :
- Bcrypt intègre un sel aléatoire et un facteur de coût ajustable.
- L’utilisation de fonctions rapides expose aux attaques par force brute et aux tables arc-en-ciel.
- Pour de nouveaux projets, considérer Argon2 selon les contraintes mémoire.
- Vérifier périodiquement le facteur de coût et gérer la troncature à 72 octets.
Dépendance du hachage envers bcrypt et protection contre les tables arc-en-ciel
Bcrypt génère un sel de 16 octets pour chaque mot de passe. Le sel est stocké dans la même chaîne que le hachage.
Cette caractéristique annule l’efficacité des tables arc-en-ciel. Ces tables contiennent des hachages précalculés d’une même entrée sans sel.
mécanisme de salage et format
La sortie bcrypt inclut la version, le facteur de coût, le sel et le hachage. Exemple : $2b$10$….
Le sel intégré évite le stockage séparé. La comparaison utilise bcrypt.compare() qui extrait le sel.
rôle du facteur de coût
Le facteur de coût double le travail à chaque incrément. Coût 10 reste une valeur courante en 2026.
Un coût trop bas augmente le débit d’attaques. Un coût trop élevé nuit à l’expérience utilisateur.
Implémentations pratiques de bcrypt dans différents langages
Voici des extraits opérants pour les langages courants. Ils montrent l’usage du facteur de coût et la vérification.
node.js — exemple
- require(‘bcrypt’)
- bcrypt.hash(plaintext, COST)
- bcrypt.compare(plaintext, storedHash)
Ce modèle évite la ré-hachage lors de la connexion. Utiliser bcrypt.compare() direct.
python, php et go — résumés
- Python : bcrypt.hashpw + bcrypt.checkpw
- PHP : password_hash avec PASSWORD_BCRYPT
- Go : golang.org/x/crypto/bcrypt
Chaque exemple respecte la même logique : génération du hachage unique et vérification via fonction dédiée.
erreurs courantes et retours d’expérience
Les erreurs listées ci-dessous reviennent fréquemment lors d’audits de sécurité.
erreurs fréquentes
- ré-hacher le mot de passe à chaque connexion
- utiliser MD5 ou SHA pour des mots de passe
- ignorer la limite de 72 octets
- choisir un facteur de coût trop bas
retours d’expérience wordpress
Retour d’expérience (WordPress) : intégration simple en plugin.
Nous avons migré 8 000 comptes vers bcrypt. Migration planifiée en batch, vérification progressive des connexions.
Retour d’expérience (WordPress) : rehash conditionnel.
Lors d’une connexion, vérifier password_needs_rehash() puis recalculer si nécessaire. Migration transparente pour l’utilisateur.
comparaison entre bcrypt, argon2 et autres algorithmes
Comparer les algorithmes sur la base de la résistance aux attaques et des contraintes.
| algorithme | mémoire requise | temps approximatif | usage recommandé |
|---|---|---|---|
| bcrypt | faible (cache) | 100-300 ms (coût 10) | authentification web |
| Argon2id | configurable, élevé | ≥ 500 ms selon paramètres | projets nouveaux, haute sécurité |
| PBKDF2 | faible | varie selon itérations | compatibilité |
| scrypt | modérée à élevée | varie | défense contre GPU |
- Choisir bcrypt pour compatibilité et simplicité.
- Considérer Argon2 quand la mémoire peut être assignée.
- Revoir les paramètres tous les deux à trois ans selon matériel.
« Le sel unique et le facteur de coût rendent les tables arc-en-ciel inefficaces contre bcrypt. »
OWASP
Témoignage : « Après migration, les tentatives de craquage ont chuté. » — ingénieur sécurité, startup fintech.
Témoignage : « La migration via rehash conditionnel a conservé l’expérience utilisateur. » — administrateur système.
Opinion : choisir un algorithme n’est pas une mode. C’est une obligation pratique pour la cryptographie des mots de passe.
Sources : USENIX 1999, OWASP password storage guide, Specops study 2024, Wikipédia.