Bcrypt

Ce qu’un hachage bcrypt contient réellement

Un hachage bcrypt est une seule chaîne de soixante caractères, et chacune de ses parties est à découvert. Rien n’y est secret sauf le mot de passe qui l’a produite, et celui-là n’y est pas du tout. La décomposer ne demande ni clé, ni mot de passe, ni le moindre calcul : cette page le fait à l’instant où vous en collez une.

• La variante, le champ par lequel la chaîne commence : $2b$, $2a$ ou $2y$. Elle dit selon les règles de qui le hachage a été produit.
• Le coût, écrit sur exactement deux chiffres : de 04 à 31. C’est un exposant, si bien qu’un coût de 12 veut dire 2^12 — 4 096 — tours d’étirement de clé, et que le coût 13 représente deux fois le travail du coût 12 et non un treizième de plus.
• Le sel, vingt-deux caractères : seize octets aléatoires, conservés en clair à côté de la réponse qu’ils ont salée.
• Le condensé, les trente et un derniers caractères : vingt-trois octets de sortie. C’est la seule partie qui dépende du mot de passe, et ce n’est pas le hachage — le hachage, c’est la chaîne entière.

L’alphabet d’où ces caractères sont tirés est celui de bcrypt lui-même, et ce n’est pas le Base64 standard : il va ./A-Za-z0-9, si bien qu’un point et une barre oblique l’ouvrent là où Base64 met le plus et la barre à la fin. Le passer dans un décodeur Base64 ordinaire rend des octets faux plutôt qu’une erreur, ce qui est une manière classique de perdre un après-midi.

La limite de soixante-douze octets se compte en octets, et ce n’est pas un détail

bcrypt lit au plus soixante-douze octets d’un mot de passe et ignore tout ce qui vient après. Pas soixante-douze caractères — soixante-douze octets d’UTF-8, si bien que le nombre de caractères que cela représente dépend de ce que coûtent les lettres de la langue : les vingt-six lettres latines sans signe coûtent un octet chacune, et toute autre lettre coûte davantage. En français l’écart est petit et réel à la fois : chaque lettre qui porte un accent, un tréma ou une cédille coûte deux octets, si bien qu’un mot de passe portant quelques accents atteint la limite un peu avant soixante-douze caractères. Un mot de passe fait uniquement de lettres accentuées l’atteindrait à trente-six.

• L’ASCII coûte un octet par caractère : celui qui parle anglais rencontre la limite à soixante-douze caractères et n’y arrive presque jamais.
• L’hébreu, l’arabe, le russe et le grec coûtent deux octets par lettre, si bien que la limite arrive à trente-six caractères.
• Le japonais, le coréen et le chinois coûtent trois, si bien qu’elle arrive à vingt-quatre.
• La plupart des émojis coûtent quatre, et beaucoup de ceux que les gens tapent vraiment sont plusieurs points de code assemblés : une poignée suffit déjà à épuiser tout le budget.

Le compteur d’octets sous le champ du mot de passe est là pour que ce soit une chose que vous voyez venir plutôt que découvrir après coup. Et la coupe tombe à l’octet et non au caractère, exactement comme le fait toute implémentation de référence — un caractère multi-octets assis sur la frontière perd donc une partie de lui-même et garde le reste. C’est le comportement compatible et non un défaut, et cette page le dit quand cela arrive.

Et voici la partie qui explique tout le reste : la troncature est invisible dans la réponse. L’expansion de la clé mêle exactement soixante-douze octets de clé à son état et n’en reboucle jamais un plus long, si bien que hacher un mot de passe de cent octets et hacher ses soixante-douze premiers octets donnent le même condensé. Il n’y a rien qu’une implémentation puisse détecter et rien qu’elle puisse signaler, et c’est pourquoi aucune bibliothèque ne lève d’erreur et pourquoi deux longs mots de passe différents qui s’accordent sur leurs soixante-douze premiers octets correspondent tous les deux au même hachage stocké. Cette page ne peut pas non plus refuser un long mot de passe — si vous le vérifiez contre un hachage qu’un vrai système a produit en tronquant, il vous faut la réponse — alors elle donne la réponse et vous dit ce qui a été coupé.

La variante change le préfixe et non le condensé

La variante ressemble à un numéro de version et n’en est pas un. Les trois que cet outil écrit ne sont pas ordonnées, aucune ne remplace les autres, et choisir entre elles est une décision de compatibilité et non de sécurité.

• $2b$ est celle sur laquelle OpenBSD s’est arrêté et celle qu’émettent aujourd’hui Python, Node et Go. C’est la valeur par défaut ici et la bonne réponse quand rien n’en impose une autre.
• $2a$ est la plus ancienne, et certains déploiements Java et Spring Security de longue date s’attendent encore à la voir.
• $2y$ est celle qu’écrit le password_hash de PHP, et donc Laravel, si bien qu’un hachage collé dans ce monde-là la réclame en général.

Ce qui sépare les trois, c’est la façon dont elles traitent une clé de plus de 255 octets, et bcrypt a déjà cessé de lire à soixante-douze — aucun mot de passe que vous pouvez taper ici n’atteint donc cette différence. Pour tout ce que cet outil recevra jamais, les trois produisent les mêmes vingt-trois octets et ne diffèrent que par les quatre caractères de tête. Changez la variante et le condensé ne bouge pas.

Il en existe deux autres, et cet outil les nomme au lieu de les calculer. $2x$ n’est pas un correctif : Openwall l’a frappée pour reproduire à dessein un bogue d’extension de signe, afin que les hachages faits par le code cassé restent vérifiables, et l’implémenter ici reviendrait à installer un défaut connu à l’intérieur de l’outil. $2$ est la variante d’origine, d’avant l’ajout de l’octet nul final à la clé. Plus rien d’actuel n’émet l’une ou l’autre ; si vous en tenez une, elle sort d’un système assez vieux pour que la variante soit le moindre de vos soucis.

Le coût, et ce qu’il coûte sur votre propre machine

Le coût est le facteur de travail, de 4 à 31, et c’est un exposant : chaque cran double le temps. C’est tout l’intérêt de bcrypt. Un hachage de mot de passe doit être lent, parce qu’un attaquant qui tient une table volée paie le même prix à chaque essai, et que doubler le coût divise par deux le nombre d’essais par seconde qu’il obtient pour son argent.

Ce qu’un coût donné prend réellement est un fait sur la machine qui l’exécute, pas un nombre qui s’écrit à l’avance : un téléphone et un serveur sont à deux ordres de grandeur l’un de l’autre. Cette page mesure donc au lieu de citer : elle lance un hachage court sur votre propre appareil au chargement et extrapole de là, ce qui explique que l’estimation à côté du réglage du coût soit vide un instant puis apparaisse. Au-delà de quelques secondes, elle demande avant de commencer, pour qu’un chiffre mal tapé ne se lise pas comme une page figée.

Pour choisir un nombre : 12 est ce qu’émettent par défaut Laravel et le paquet bcrypt de Python, et c’est aujourd’hui un plancher de production raisonnable. Les coûts plus bas sont pour les fixtures de test, où une suite qui sème cinquante utilisateurs ne devrait pas passer une seconde par utilisateur. Les coûts au-dessus de 15 environ méritent d’être mesurés contre votre vrai trafic de connexion avant d’être livrés, puisque chaque connexion en paie le prix elle aussi.

# Apache : écrire une ligne htpasswd au coût 12
htpasswd -nbBC 12 alice "correct horse battery staple"

# PHP et Laravel : password_hash émet $2y$
php -r 'echo password_hash("correct horse battery staple", PASSWORD_BCRYPT);'

# Python : le paquet bcrypt émet $2b$, et gensalt prend le coût
python -c "import bcrypt; print(bcrypt.hashpw(b'correct horse battery staple', bcrypt.gensalt(12)))"

Le sel, et quand un hachage fait ici n’est pas à stocker

Le sel, ce sont seize octets aléatoires tirés neufs pour chaque hachage, et il est conservé en clair à l’intérieur de la chaîne. Ce n’est pas un secret et cela n’a jamais été prévu pour en être un : son travail est de faire que deux mots de passe identiques produisent deux hachages sans rapport, pour qu’une table volée ne puisse pas être attaquée avec un seul dictionnaire précalculé.

C’est aussi pourquoi le même mot de passe vous donne ici un hachage différent à chaque appui sur le bouton. Ce n’est pas un défaut et l’ancienne réponse n’est pas périmée : un sel neuf, c’est bcrypt qui fonctionne. N’importe lequel de ces hachages correspond au mot de passe, parce que le sel voyage à l’intérieur de la chaîne que l’on vérifie.

Le champ avancé du sel existe pour une seule tâche : reproduire exactement le hachage de quelqu’un d’autre, afin de pouvoir mettre deux implémentations face à face. Collez-y un hachage entier et le coût et la variante le suivent automatiquement, si bien que le bon mot de passe reproduit l’entrée caractère pour caractère. Tout ce que vous produisez ainsi sert à comparer et non à stocker : un sel employé deux fois est un sel qui a cessé de faire son travail.

Un hachage bcrypt ne s’inverse pas

On arrive sur des pages comme celle-ci en cherchant un moyen de déchiffrer un hachage bcrypt. Il n’y en a pas, et la raison n’est pas que ce soit difficile : le mot de passe n’est pas dans la chaîne. Soixante caractères portent une variante, un coût, seize octets aléatoires et vingt-trois octets de sortie, et aucun arrangement de tout cela ne contient un mot de passe d’une longueur quelconque. Rien n’a été chiffré, il n’y a donc rien à déchiffrer.

Ce qu’un site peut faire — et ce que font ceux qui annoncent du déchiffrement — c’est deviner. On prend une liste de mots de passe courants, on hache chacun contre votre sel et à votre coût, et on regarde si l’un d’eux correspond. bcrypt est conçu pour rendre exactement cela coûteux, ce à quoi sert le coût, et cet outil ne le propose sous aucune forme.

La version honnête de cette question en est généralement une autre, et celle-là a une réponse : qu’y a-t-il dans cette chaîne, et ce mot de passe précis la produit-il ? Les deux sont sur cette page. Collez le hachage pour voir tout ce qu’il porte, et ajoutez un mot de passe pour obtenir un oui ou un non.