Générateur de hachage bcrypt pour mots de passe

Lire cette chaîne étrange qu'il vous donne

Un hachage bcrypt ressemble à du bruit de ligne, mais il a une anatomie fixe qui mérite d'être connue. Il commence par un marqueur de version tel que $2a$ ou $2b$, suivi du facteur de coût que vous avez choisi, puis de vingt-deux caractères de sel aléatoire, et enfin des trente et un caractères du hachage proprement dit. Tout ce dont un vérificateur a besoin voyage à l'intérieur de cette seule chaîne — c'est pourquoi l'ensemble tient dans une seule colonne de base de données, et pourquoi générer un hachage pour le même mot de passe deux fois donne deux chaînes différentes qui sont pourtant toutes deux valides. Le sel diffère à chaque fois, donc le résultat diffère à chaque fois ; quand votre back-end vérifie plus tard une connexion, il relit le sel dans la chaîne stockée, hache la tentative avec, et compare le résultat.

Où vous utiliseriez réellement cette page

La plupart du temps, le hachage bcrypt se produit à l'intérieur de votre application, pas dans un navigateur — mais il y a des moments où un hachage fabriqué à la main est exactement ce qu'il vous faut. Amorcer une base de données de test avec des comptes dont vous connaissez les mots de passe. Sauver un compte administrateur bloqué en écrivant un hachage tout frais directement dans la table des utilisateurs. Vérifier quelle forme de chaîne une bibliothèque va produire avant de dimensionner la colonne en conséquence. Dans tous ces cas, vous collez un mot de passe, copiez le hachage, et le placez là où votre code de connexion en attend un. Une chose à ne jamais faire : comparer des hachages sous forme de chaînes dans votre propre code. À cause du sel, le même mot de passe produit des hachages différents — la vérification doit passer par la fonction de comparaison de votre bibliothèque, qui sait comment relire le sel.

Choisir un coût que vous pouvez assumer

Chaque cran du facteur de coût double le travail, pour vous comme pour un attaquant. Huit est rapide et mieux réservé à la compatibilité avec d'anciens systèmes ; dix, la valeur par défaut ici, est le choix courant en production ; douze offre du confort si les connexions sont rares ; quatorze prend des secondes rien que pour générer. Un avertissement honnête sur le chronométrage : cette page exécute une implémentation JavaScript pure, plus lente que le code natif de votre serveur, alors traitez le délai que vous ressentez ici comme une borne supérieure plutôt que comme un test de référence — mesurez sur la machine qui gérera réellement les connexions. Et comme un hachage ne vaut que ce que vaut ce qu'on y met, le générateur de mots de passe fournit une bonne entrée solide, tandis que tout ce qui n'est pas un mot de passe — fichiers, documents, texte brut — relève plutôt du générateur de hachage SHA.

Pourquoi bcrypt plutôt qu'un hachage classique

Un hachage SHA classique d'un mot de passe peut être cassé rapidement sur du matériel moderne. Bcrypt est volontairement lent — le facteur de coût contrôle précisément à quel point — et sale automatiquement, de sorte que le même mot de passe ne produit jamais deux fois le même hachage stocké. C'est pourquoi il reste un choix standard pour stocker des mots de passe côté serveur.