Calculatrice du facteur de coût bcrypt | Calibrez bcrypt sur votre propre CPU, pas sur une table générique

La consigne classique d'OWASP (« utilisez un coût de 12 ») et les tableaux de vitesse qu'on trouve dans les blogs sont d'excellents points de départ, mais ils ont été écrits pour le matériel de quelqu'un d'autre. Le bon facteur de coût dépend du CPU précis sur lequel tourne votre production, du conteneur qui l'enveloppe et de la charge réellement supportée. Cette page exécute bcryptjs dans votre propre navigateur, facteur après facteur, jusqu'à trouver le plus élevé qui tient encore dans votre budget de latence de connexion.

💡 À propos de cet outil

Chaque incrément du facteur de coût bcrypt double la quantité de travail à effectuer. Si le coût 10 prend 50 ms sur une machine, le coût 12 prendra environ 200 ms et le coût 14 environ 800 ms. Cette croissance exponentielle est précisément ce qui donne à bcrypt sa résistance face aux attaques par force brute, mais cela signifie aussi qu'un écart d'un ou deux crans laisse soit un parcours de connexion poussif, soit un stockage de mots de passe plus faible que prévu.

La mesure parcourt les facteurs du coût 4 jusqu'au plafond que vous avez choisi, hashe un mot de passe factice avec bcryptjs à chaque cran et affiche le temps mesuré ligne par ligne. Le coût le plus élevé qui tient sous votre cible est mis en évidence, et le préfixe $2b$NN$ correspondant apparaît juste en dessous — c'est exactement le préfixe que porteront vos hashes stockés, vous pouvez donc le coller dans un test unitaire ou dans le README de déploiement. Si une ligne dépasse 8 secondes, l'exécution s'arrête automatiquement pour qu'un ordinateur ARM lent ne fige pas la page pendant trente secondes.

La chaîne saisie dans « mot de passe d'exemple » n'est transmise qu'à bcrypt.hash() dans votre navigateur. Elle n'est envoyée nulle part, mais évitez tout de même de coller un véritable mot de passe de production dans un champ de test : la valeur par défaut ou n'importe quelle chaîne jetable suffit.

🧐 Questions fréquentes

Q. Quel facteur viser dans un contexte ANSSI / RGPD, où la traçabilité prime ? A. L'ANSSI ne fixe pas de coût bcrypt précis dans ses guides Authentification et mots de passe ; elle renvoie aux algorithmes recommandés (Argon2id, scrypt, bcrypt selon contexte) et exige une calibration documentée. Concrètement : journaliser dans la procédure de mise en production le matériel testé, le coût retenu et le temps de hachage observé. Cet outil vous donne précisément ce chiffre à reporter dans la PSSI ou le dossier d'homologation.

Q. Faut-il rester sur bcrypt ou passer à Argon2id ? A. Pour un nouveau système, Argon2id est la première recommandation OWASP, parce qu'il est memory-hard et limite l'usage de fermes GPU pour la force brute. bcrypt reste pertinent quand l'écosystème vous y oblige : Symfony password_hash(), Laravel par défaut, Rails Devise, ASP.NET Identity, ponts Active Directory. Cet outil répond à la question pragmatique « nous tenons bcrypt, quel coût mettre ? », pas à « quel algorithme choisir vierge ? ».

Q. Pourquoi la première ligne du tableau est-elle aberrante ? A. Le premier appel bcrypt.hash() paie le préchauffage du JIT V8 et le chargement du module depuis esm.sh. Relancez la mesure une seconde fois et fiez-vous à la deuxième passe pour les décisions limites. Des variations de 5 à 10 % entre exécutions sont normales : bcryptjs est du JavaScript mono-thread, pas du code natif à temps constant.

Q. Si je monte le coût, les utilisateurs existants perdent-ils leur mot de passe ? A. Non. Le coût est gravé dans chaque hash ($2b$10$... versus $2b$12$...), donc les hashes anciens continuent d'être vérifiés avec leur coût d'origine. La bonne pratique est de re-hasher à la connexion : quand l'authentification réussit, contrôlez bcrypt.getRounds() et, si le résultat est inférieur à la nouvelle cible, recalculez le hash avec le coût plus élevé et écrasez la ligne. La transition s'étale ainsi sur plusieurs semaines de trafic normal.

Q. Mon MacBook annonce coût 13 en 180 ms, mon serveur Scaleway peine au coût 11. Lequel choisir ? A. Toujours le serveur. Apple Silicon a une hiérarchie mémoire qui rend bcrypt anormalement rapide, donc un coût calibré sur Mac sera systématiquement trop ambitieux sur un x86 modeste. Ouvrez cette page depuis une session sur la machine de production (port forward SSH, Cloud Run, Scaleway Function avec shell navigateur) et fiez-vous à ce résultat.

📚 Le saviez-vous

Le nombre stocké dans $2b$NN$ n'est pas le nombre de tours — c'est le log₂ du nombre de tours. Coût 12 = 4 096 tours, coût 13 = 8 192, coût 31 (maximum théorique) = 2 147 483 648 tours. Cet encodage logarithmique explique pourquoi la spécification n'a besoin que de deux caractères pour le facteur de coût tout en offrant un intervalle de mille pour un.

Les préfixes 2a, 2b, 2x, 2y que l'on croise dans les bases anciennes ne sont pas des algorithmes différents mais des générations de corrections de bugs. $2a$ est la version originale d'OpenBSD de 1999 ; $2x$ et $2y$ sont des marqueurs spécifiques à PHP datant de 2011, après un correctif de Crypt_Blowfish ; $2b$ est le préfixe moderne, conforme à la spécification, que vous devez générer aujourd'hui. La plupart des vérificateurs acceptent les quatre par compatibilité, mais les nouveaux hashes — y compris le préfixe produit par cet outil — utilisent $2b$.