bcrypt pour le hachage des mots de passe Pourquoi la seule encryption ne suffit pas

Si vous stockez les mots de passe des utilisateurs avec AES, RSA ou même SHA-256, vous faites une erreur. Pas une erreur légère — une erreur fondamentale. C'est la plus commune erreur de sécurité en développement web, et elle a une solution simple : utilisez une fonction de hachage de mot de passe appropriée comme bcrypt.

Voici pourquoi cela importe, comment fonctionne bcrypt, et quelle est la version de code prête pour la production.

Pourquoi les mots de passe nécessitent un traitement spécial

La plupart des opérations cryptographiques sont conçues pour être inversibles ou rapides. L'encryption est conçue pour être inversible — c'est son but. SHA-256 et MD5 sont rapides, traitant des gigabits par seconde. Ces deux propriétés sont catastrophiques pour les mots de passe.

Lorsqu'un attaquant obtient votre base de données, il obtient vos hachages de mots de passe. Avec l'encryption, s'il trouve la clé, il déchiffre tout. Avec des hachages rapides comme MD5 ou SHA-256, il lance une attaque par force brute accélérée par GPU — les équipements modernes peuvent tester des centaines de milliards de hachages MD5 par seconde. Votre « mot de passe » complexe est cassé en quelques minutes.

Les mots de passe doivent être :

1. Non inversibles — même avec la clé ou l'algorithme, vous ne pouvez pas récupérer le texte brut
2. Lents à calculer — une lenteur volontaire rend les attaques par force brute impraticables
3. Uniques par utilisateur — des mots de passe identiques doivent produire des hachages différents

bcrypt satisfait aux trois critères. Les fonctions de hachage générales et l'encryption ne le font pas.

Hachage vs Encryption vs Hachage des mots de passe

Ce ne sont pas interchangeables :

Approche	Inversible ?	Rapide ?	Sécurisé pour les mots de passe ?
Encryption (AES, RSA)	Oui — avec la clé	Oui	Non
Hachage rapide (MD5, SHA-256)	Non	Oui (par conception)	Non
Hachage des mots de passe (bcrypt, Argon2id)	Non	Non (par conception)	Oui

L'inversibilité de l'encryption est un point critique : compromettre la clé, c'est compromettre tous les mots de passe. Le hachage rapide est aussi un point critique : la vitesse permet des attaques par force brute. Les fonctions de hachage des mots de passe sont conçues pour être lentes — et c'est le point.

Comment fonctionne bcrypt

bcrypt, conçu en 1999 par Niels Provos et David Mazières, fait trois choses importantes :

1. Le salage. Avant le hachage, bcrypt génère un sel aléatoire (16 octets) et l'intègre dans la sortie du hachage. Même si deux utilisateurs partagent le même mot de passe, leurs hachages sont différents. Cela élimine entièrement les attaques par tables de pré-calcul.

2. Le facteur de travail (coût). bcrypt accepte un paramètre de coût (généralement 10 à 14). Chaque augmentation double le temps de calcul. À un coût de 12, le hachage dure environ 250 à 400 ms sur des équipements modernes. Cela est imperceptiblement lent pour une demande de connexion — mais il transforme une attaque par force brute de milliards d'essais en une opération de décennies.

3. La sortie est autonome. Un hachage bcrypt ressemble à $2b$12$... et encode la version de l'algorithme, le facteur de coût, le sel et le hachage ensemble. Vous n'avez pas besoin d'une colonne séparée pour le sel. Stockez la chaîne complète.

Code de production : Node.js et Python

Node.js (bcryptjs ou bcrypt)

const bcrypt = require('bcrypt');

const SALT_ROUNDS = 12;

// Hash a password
async function hashPassword(plaintext) {
  return bcrypt.hash(plaintext, SALT_ROUNDS);
}

// Verify a password against a stored hash
async function verifyPassword(plaintext, storedHash) {
  return bcrypt.compare(plaintext, storedHash);
}

// Usage
const hash = await hashPassword('hunter2');
// Store `hash` in your database

const isValid = await verifyPassword('hunter2', hash);
// true

Python (bcrypt)

import bcrypt

COST = 12

def hash_password(plaintext: str) -> bytes:
    salt = bcrypt.gensalt(rounds=COST)
    return bcrypt.hashpw(plaintext.encode('utf-8'), salt)

def verify_password(plaintext: str, stored_hash: bytes) -> bool:
    return bcrypt.checkpw(plaintext.encode('utf-8'), stored_hash)

# Usage
hashed = hash_password('hunter2')
# Store hashed in your database

is_valid = verify_password('hunter2', hashed)
# True

Stockez la chaîne complète du hachage. Ne stockez jamais le texte brut, ne stockez jamais le sel séparément, ne stockez jamais les valeurs intermédiaires.

Choisir un facteur de coût

Le bon facteur de coût dépend de votre matériel. L'objectif : faire durer chaque opération de hachage 200 à 500 ms sur votre serveur de production. Cela est suffisant pour une bonne expérience utilisateur, lent assez pour frustrer les attaquants.

Recommandation actuelle : coût 12 comme minimum, 14 pour les comptes à haut valeur (administrateur, financier). Faites un test sur votre matériel réel :

// Node.js: benchmark different cost factors
const bcrypt = require('bcrypt');

for (let cost = 10; cost <= 14; cost++) {
  const start = Date.now();
  await bcrypt.hash('benchmark', cost);
  console.log(`Cost ${cost}: ${Date.now() - start}ms`);
}

Si le coût 12 dure moins de 100 ms, augmentez-le. Si le coût 14 dure plus de 1000 ms, réduisez à 13. Revoyez annuellement — le matériel devient plus rapide, et votre facteur de coût doit s'adapter.

Vous pouvez tester le hachage bcrypt de manière interactive avec le générateur de hachage bcrypt IO Tools.

bcrypt vs Argon2id vs scrypt

bcrypt est éprouvé et largement supporté. Mais il a une limitation : il n'est pas mémoire-intensif. Un attaquant avec un matériel spécialisé (ASICs ou FPGAs) peut paralléliser ses attaques plus efficacement que avec des alternatives mémoire-intensives.

Algorithme	Mémoire-intensif	Résistant à la parallélisation	Recommandation
bcrypt	Non	Partiel	Bon paramètre par défaut ; utilisez un coût ≥12
scrypt	Oui	Partiel	Meilleur que bcrypt, moins de outils
Argon2id	Oui	Oui	Préféré pour les nouveaux projets

Pour les nouveaux projets : utilisez Argon2id. Il a gagné la compétition de hachage des mots de passe (2015), est mémoire-intensif, résiste aux attaques par GPU et ASIC, et est maintenant recommandé par OWASP. L'API est presque identique à bcrypt.

Pour les projets existants : si vous êtes déjà sur bcrypt avec un coût raisonnable, le passage n'est pas urgent. Ajoutez-le à votre prochaine refonte majeure.

Erreurs courantes dans l'implémentation

Hachage du hachage. Certains développeurs hachent le mot de passe côté client avant de l'envoyer, puis le hachent à nouveau côté serveur. Le hachage côté client devient le « mot de passe ». Vous hachiez maintenant une chaîne hexadécimale de longueur fixe, pas un mot de passe choisi par l'utilisateur — vous perdez rien par le double hachage, mais vous gagnez rien non plus, et vous introduisez de la confusion.

Le problème de la troncation de 72 octets. bcrypt ignore silencieusement tout ce qui dépasse 72 octets. Un mot de passe de 100 caractères et un mot de passe de 72 caractères qui partagent les 72 premiers caractères sont identiques pour bcrypt. Si vos utilisateurs définissent des mots de passe très longs, cela représente une dégradation de sécurité silencieuse. Solution : pré-hachage avec SHA-256 avant de le passer à bcrypt — mais uniquement si vous comprenez pleinement les implications, et que vous le documentez clairement.

Facteur de coût faible. Un coût de 10 était raisonnable en 2011. En 2026, utilisez au moins 12. Si vos enregistrements existants utilisent un coût de 10, vous pouvez les mettre à jour de manière transparente : après une connexion réussie, ré-hachagez le mot de passe vérifié avec le nouveau coût et stockez le hachage mis à jour.

L'asynchronisme compte. bcrypt est intensif en CPU. Utilisez toujours l'API asynchrone (comme ci-dessus) dans Node.js pour éviter de bloquer la boucle d'événements. L'utilisation synchrone de bcrypt sur un serveur Node rendra chaque autre requête en attente.

Passer de MD5/SHA à bcrypt

Vous ne pouvez pas ré-hachagez sans le texte brut original. Mais vous pouvez passer de manière opportuniste :

1. Ajoutez une password_hash colonne à côté de l'ancienne password_md5 column
2. Lors d'une connexion réussie (quand vous avez le texte brut), hachagez-le avec bcrypt et stockez-le dans password_hash, supprimez la colonne ancienne
3. Après une période de migration, les utilisateurs qui n'ont pas connecté peuvent être forcé de réinitialiser leur mot de passe
4. Une fois password_md5 est vide pour tous les utilisateurs, supprimez la colonne

C'est l'approche standard et nécessite aucune interruption.

Pour conclure

L'encryption est pour les données que vous devez récupérer. Le hachage est pour les données que vous devez vérifier. Les mots de passe doivent être vérifiés, pas récupérés — ce qui signifie que l'encryption est l'outil inapproprié.

bcrypt vous donne le salage, une lenteur configurable, et un format de hachage autonome. C'est la bonne réponse depuis 25 ans. Utilisez-le avec un coût de 12 ou plus, utilisez Argon2id pour les nouveaux projets, et passez de MD5 et SHA-256 dès que possible.

Faire cela mal n'est pas un risque hypothétique. Les bases de données sont compromises. Lorsqu'elles le sont, les mots de passe hachés correctement avec bcrypt sont computatoirement impraticables à casser. Les hachages MD5 sont cassés en une nuit.

Vous aimerez peut-être aussi