Générateur et vérificateur de hachage bcrypt

À propos de cet outil

Pourquoi bcrypt est lent exprès

Les bases de mots de passe se font voler, et celui qui en détient une peut deviner les mots de passe hors ligne, aussi vite que son matériel le permet. Les hachages généralistes comme SHA-256 sont conçus pour être rapides : une seule carte graphique teste des milliards de candidats par seconde. bcrypt, publié par Niels Provos et David Mazières en 1999, repose sur la coûteuse préparation de clé du chiffrement Blowfish et la répète un nombre de fois configurable, ce qui rend chaque tentative coûteuse.

Chaque hachage porte aussi son propre sel aléatoire de 16 octets. Deux utilisateurs ayant le même mot de passe obtiennent des hachages différents, et une table précalculée pour un sel ne sert à rien pour le suivant. Un hachage bcrypt ne peut pas être déchiffré. L'attaque possible en pratique consiste à deviner : un mot de passe faible tombe donc vite, quel que soit le coût.

Ce que signifie le coût et comment le choisir

Le coût est le logarithme en base 2 du nombre de tours de préparation de clé : un coût de 10 correspond à 1 024 tours, un coût de 12 à 4 096. Ajouter 1 double le temps d'une connexion et de chaque tentative d'un attaquant. Le coût est inscrit dans le hachage, vous pouvez donc l'augmenter plus tard : les anciens hachages restent vérifiables, et vous pouvez rehacher un mot de passe au nouveau coût lors de la prochaine connexion de son propriétaire.

Choisissez le coût le plus élevé que votre serveur peut se permettre pour une connexion, et pas moins de 10, le minimum indiqué pour bcrypt par l'OWASP Password Storage Cheat Sheet. Le temps affiché ici est mesuré en WebAssembly dans votre navigateur, ce qui est généralement plus lent que du code natif sur un serveur : mesurez donc sur la machine qui fera le hachage. C'est pour cette raison que cet outil s'arrête à un coût de 14.

La limite de 72 octets

bcrypt utilise au plus 72 octets du mot de passe. La limite est en octets, pas en caractères : en UTF-8, une lettre accentuée comme é occupe deux octets, la plupart des caractères CJK trois et la plupart des emoji quatre ou plus. Beaucoup de bibliothèques tronquent une entrée plus longue sans prévenir : deux longs mots de passe qui partagent leurs 72 premiers octets sont alors validés par le même hachage. L'implémentation Go utilisée ici refuse de hacher une entrée plus longue, et cet outil vous le signale quand c'est le cas.

Si vos utilisateurs peuvent choisir des mots de passe plus longs, la solution simple est de les refuser à l'inscription avec un message clair. Un contournement courant hache d'abord le mot de passe en SHA-256 et passe à bcrypt le texte Base64 ou hex de cette empreinte. Il ne doit pas passer les octets bruts de l'empreinte, car certaines implémentations s'arrêtent de lire à un octet nul, et la cheat sheet de l'OWASP déconseille ce type de pré-hachage, car il ouvre la voie à une attaque appelée password shucking. Pour un nouveau système, l'OWASP recommande Argon2id plutôt que bcrypt, et Argon2id n'a pas de limite de 72 octets.

Lire un hachage, et comment fonctionne cet outil

Un hachage bcrypt fait 60 caractères : un préfixe de version comme $2b$, un coût à deux chiffres et $, 22 caractères de sel et 31 caractères d'empreinte, les deux dans l'alphabet Base64 propre à bcrypt (./A-Za-z0-9). Tout ce qu'il faut pour vérifier un mot de passe tient dans cette seule chaîne : il n'y a pas de colonne séparée pour stocker le sel.

Le hachage et la vérification sont assurés par le package golang.org/x/crypto/bcrypt de Go, compilé en WebAssembly et exécuté dans un thread d'arrière-plan de votre navigateur. Les mots de passe et les hachages ne sont envoyés nulle part et ne sont pas conservés. Cette page est faite pour les données de test, les fixtures et la vérification d'un hachage que vous avez déjà : les mots de passe de vrais utilisateurs doivent être hachés par votre application, sur votre serveur.