Générateur bcrypt - Créer des hachages de mot de passe en ligne

Pour la plupart des systèmes de production, un facteur de travail de 12 constitue une valeur par défaut raisonnable, soit environ 250 à 400 millisecondes par hachage sur du matériel serveur classique, tandis que le coût 10 est désormais souvent trop rapide pour résister à un attaquant équipé de GPU modernes. La propriété essentielle est de choisir une valeur qui rende votre propre parcours de connexion ordinaire : le hachage se produit pendant l'authentification et toute lenteur perceptible devient un problème d'ergonomie qui pousse vers des raccourcis de réauthentification. Si vos serveurs sont particulièrement puissants, mesurez au coût 12 puis montez à 13 ou 14 jusqu'à ce qu'un hachage prenne quelques centaines de millisecondes. Ne reprenez jamais le coût d'un autre projet, car cette valeur n'a de sens que par rapport au matériel qui exécute le travail : traitez tout coût stocké comme une valeur à remesurer et à augmenter au fil des progrès matériels.

Parce que bcrypt génère un sel aléatoire de 128 bits entièrement nouveau pour chaque hachage. Ce sel n'est pas un secret : il est simplement consigné dans la sortie afin que l'étape de vérification puisse reproduire le calcul initial. Mais son caractère aléatoire garantit que des mots de passe identiques produisent des chaînes de hachage sans lien entre elles d'un compte à l'autre. Cela met en échec une grande famille d'attaques par précalcul, notamment les tables arc-en-ciel, où l'attaquant hache une fois pour toutes les mots de passe probables puis consulte une table de correspondance. Cela empêche aussi une fuite plus subtile : un attaquant qui obtient votre table d'utilisateurs ne peut plus repérer d'un coup d'œil quels comptes partagent un mot de passe en comparant les chaînes. La conséquence pratique est que vous ne pouvez pas détecter un mot de passe réutilisé en comparant des hachages bcrypt stockés : il faut vérifier des mots de passe candidats, et c'est précisément pourquoi la détection de réutilisation exige d'essayer volontairement un mot de passe sur d'autres comptes.

Utilisez bcrypt, et la raison tient au facteur de coût bien plus qu'à une quelconque subtilité mathématique. Une passe de SHA-256 est conçue pour être extrêmement rapide, et c'est exactement ce que vous ne voulez pas pour du stockage de mots de passe, car un GPU peut en calculer des milliards par seconde et un attaquant qui teste une table de hachages volée obtient un nombre considérablement élevé d'essais gratuits. bcrypt est intentionnellement lent et son coût par hachage est réglable : vous pouvez l'augmenter au fil du temps à mesure que le matériel progresse sans changer le format stocké. Argon2id est désormais souvent préféré lorsqu'il est disponible et constitue généralement la recommandation la plus solide pour les systèmes neufs, bcrypt restant parfaitement acceptable et bien plus largement pris en charge. Ce que vous ne devez jamais faire, c'est stocker des mots de passe en SHA-256 brut, ou sous forme de hachage sans sel, quel que soit l'algorithme retenu.

Non, et c'est là toute l'intérêt d'avoir choisi un hachage plutôt qu'un chiffrement. bcrypt est une fonction à sens unique : il n'existe aucune clé, aucun réglage et aucun outil payant qui transforme un hachage en mot de passe. La seule manière pratique de récupérer un mot de passe à partir d'un hachage bcrypt consiste à deviner des mots de passe candidats, à hacher chacun avec le même coût et le même sel, puis à comparer, ce qui est précisément l'attaque que bcrypt est conçu pour rendre lente. Cela explique aussi une contrainte qui surprend : vous ne pouvez pas utiliser bcrypt pour ce que vous devez relire plus tard, comme un numéro de carte stocké, une clé de chiffrement client ou une récupération de mot de passe réversible, car le système serait incapable de retrouver la valeur d'origine. Ces cas exigent un véritable chiffrement avec une clé gérée, non un hachage à sens unique.

Le hachage ne pourra jamais être vérifié et le compte deviendra irrécupérable, car bcrypt a besoin des quatre parties de la chaîne pour reproduire le calcul. Un hachage bcrypt complet est le préfixe de version, le coût, le sel et le hachage obtenu, reliés par des signes dollar, et il fait toujours 60 caractères de long. Des bibliothèques telles que bcryptjs et le paquet bcrypt de Python renvoient cette chaîne entière depuis un seul appel de génération : votre colonne en base de données doit donc stocker la valeur complète plutôt qu'une portion tronquée. Stocker uniquement le dernier segment, ou seulement la partie située après le sel, casse silencieusement la connexion de tous les utilisateurs, et aucun débogage du mot de passe lui-même n'y remédie. Un contrôle de longueur à 60 caractères constitue un bon test de cohérence pour toute colonne censée contenir des hachages bcrypt.

bcrypt ne considère que les 72 premiers octets du mot de passe et ignore tout ce qui suit, artefact historique de son ordonnancement de clé Blowfish plutôt que limite de sécurité délibérée. La conséquence pratique est que deux mots de passe dépassant 72 octets et partageant un même préfixe s'authentifieront l'un comme l'autre : une phrase de passe de 100 caractères dont les 72 premiers octets correspondent à une autre serait traitée comme le même mot de passe. Le risque est réel avec les longues phrases de passe, qui sont exactement le type de mot de passe à encourager, et des valeurs longues telles que des phrases complètes dépassent volontiers la limite. Le remède standard consiste à préhacher le mot de passe avec SHA-256 puis base64, et à transmettre ce résultat de longueur fixe à bcrypt. Si votre bibliothèque le fait automatiquement, préférez cette implémentation ; sinon, vérifiez le comportement avant de compter sur de très longues phrases de passe.