Bcrypt s'appuie sur Blowfish, le chiffrement par blocs conçu par Bruce Schneier en 1993 — bien avant que « ralentir volontairement une fonction » ne devienne un principe reconnu en sécurité des mots de passe. Ce que Niels Provos et David Mazières ont remarqué en 1999, c'est que la phase d'initialisation des clés de Blowfish est anormalement lente : elle recalcule plusieurs fois des tables internes avant même de chiffrer le premier octet. Plutôt que d'y voir un défaut, ils en ont fait la base de bcrypt.
Pourquoi la rapidité nuit à la sécurité des mots de passe
Si un attaquant vole une base de hachages, il tente de retrouver le mot de passe d'origine par force brute. Avec une fonction rapide comme SHA-256, le matériel moderne teste des milliards de combinaisons par seconde. Si le hachage d'un seul mot de passe prend volontairement une centaine de millisecondes, la force brute devient des ordres de grandeur plus lente et coûteuse.
Qu'est-ce que le cost factor
Le paramètre "cost" de bcrypt fixe le nombre de tours internes comme une puissance de deux (2^cost, généralement entre 10 et 12). Chaque incrément double le temps de calcul d'un hachage — et double d'autant le coût total d'une attaque par force brute, ce qui permet d'ajuster l'algorithme au fil des ans sans en changer.
Sel intégré
Bcrypt génère automatiquement un sel aléatoire unique pour chaque mot de passe et l'intègre directement dans le résultat — rien à stocker séparément. Deux mots de passe identiques produisent des hachages différents, et les tables précalculées (rainbow tables) pour les mots de passe courants deviennent inutiles : chaque hachage doit être attaqué individuellement.
Pourquoi c'est utile
- Stocker correctement les mots de passe des utilisateurs dans la base de données d'une application.
- Comprendre pourquoi SHA-256 ou MD5 sont un mauvais choix pour le hachage de mots de passe.
- Tester ou migrer un système d'authentification utilisant bcrypt.
Une limite cachée : 72 octets
Parce qu'il repose sur le calendrier de clés de Blowfish limité à 448 bits, bcrypt ne traite que les 72 premiers octets d'un mot de passe — au-delà, tout est silencieusement ignoré, une conséquence directe du chiffrement sous-jacent plutôt qu'un choix arbitraire. En pratique, c'est rarement un problème pour des mots de passe en français (72 caractères ASCII, c'est déjà considérable), mais cela vaut la peine d'être su, notamment avec des phrases de passe longues contenant des accents.