Générateur Bcrypt

Générateur Bcrypt en Ligne — Gratuit, 100% Côté Client, Sans Inscription

Générez et vérifiez des hashes bcrypt entièrement dans votre navigateur — aucun serveur, aucune donnée enregistrée. Tout le traitement s'effectue localement avec bcryptjs, une implémentation bcrypt en JavaScript pur. Ouvrez DevTools, observez l'onglet Network complètement vide et constatez par vous-même : votre mot de passe ne quitte jamais votre machine.

Cet outil va bien au-delà du flux basique générer-et-vérifier. Mesurez le temps de hachage réel sur votre matériel pour chaque facteur de coût, analysez n'importe quel hash bcrypt existant pour comprendre sa structure, et copiez du code prêt à l'emploi pour huit langages de programmation.

Comment Utiliser le Générateur Bcrypt

Obtenir un hash bcrypt à partir d'un mot de passe prend moins de cinq secondes :

1. Collez ou tapez votre mot de passe dans le champ "Input Password" — le badge "CLIENT-SIDE SECURE" confirme qu'aucune requête réseau ne sera effectuée.
2. Ajustez le facteur de coût avec le slider (4–18). Le coût 12 est la valeur par défaut recommandée par OWASP ; des valeurs plus élevées augmentent la sécurité mais aussi le temps de hachage.
3. Cliquez sur "Generate Bcrypt Hash" — le hash apparaît immédiatement, avec le temps exact que cela a pris sur votre appareil actuel.
4. Copiez le hash avec le bouton de copie ou appuyez sur Shift+Entrée en dehors des champs de saisie.

Pour vérifier un mot de passe contre un hash existant, passez à l'onglet Verify Hash, entrez les deux valeurs et cliquez sur "Verify Match".

Exemples de Hash Bcrypt

Bcrypt produit toujours une chaîne de exactement 60 caractères. En raison du sel aléatoire, hacher deux fois le même mot de passe produira toujours des hashes différents — mais les deux vérifieront correctement le mot de passe original.

Exemple — facteur de coût 12 (défaut OWASP) :

Entrée : monsecretmotdepasse
Sortie : $2b$12$nOUIs5kJ7naTuTFkBy1veuK0kSxUFXfuaOKdOKf9xYT0KKIGSJwFa

Exemple — même mot de passe, hashes différents :

Entrée : monsecretmotdepasse (haché deux fois au coût 12)
Hash 1 : $2b$12$nOUIs5kJ7naTuTFkBy1veu...
Hash 2 : $2b$12$aBcDeFgHiJkLmNoPqRsTuv...  ← sel différent, tous deux valides

Cas limite — la limite de 72 octets :

Entrée 1 : [72 caractères 'a']
Entrée 2 : [100 caractères 'a']
Résultat : les deux produisent des hashes équivalents — les octets au-delà de 72 sont ignorés silencieusement

Format du Hash Bcrypt — Ce Que Signifie Chaque Partie

Chaque hash bcrypt a exactement la même structure. Pour $2b$12$nOUIs5kJ7naTuTFkBy1veuK0kSxUFXfuaOKdOKf9xYT0KKIGSJwFa :

Les préfixes de version : $2a$ est la spec originale avec un bug sur les caractères 8 bits ; $2b$ est le standard corrigé actuel ; $2y$ est l'équivalent PHP de $2b$. Toujours utiliser $2b$ dans le nouveau code.

Qu'est-ce que Bcrypt et Pourquoi C'est Important ?

Bcrypt est une fonction de hachage de mots de passe conçue par Niels Provos et David Mazières en 1999, basée sur le chiffrement Blowfish. Contrairement à MD5 ou SHA-256 — qui sont des fonctions rapides à usage général — bcrypt est intentionnellement lent. Son facteur de coût est ajustable, ce qui permet d'augmenter le travail de calcul à mesure que le matériel s'améliore, rendant les attaques par force brute économiquement non rentables.

Bcrypt génère et intègre automatiquement un sel aléatoire unique dans chaque hash. Cela empêche les attaques par table arc-en-ciel, où des attaquants utilisent des tables précalculées pour inverser des hashes courants. Même si deux utilisateurs ont des mots de passe identiques, leurs hashes bcrypt seront différents.

Cas d'Usage Courants

• Systèmes d'authentification : Hacher les mots de passe avant de les stocker en base de données. À la connexion, bcrypt.compare() exécute le même algorithme avec le sel stocké et confirme la correspondance en temps constant, prévenant les attaques temporelles.
• Migration depuis des algorithmes faibles : Re-hacher progressivement les mots de passe de MD5/SHA-1 vers bcrypt. Lors d'une connexion réussie avec l'ancien hash, vérifier le mot de passe et remplacer immédiatement le hash stocké par un bcrypt.
• Calibration du facteur de coût : Exécuter le benchmark local sur le matériel de votre serveur de production pour trouver le facteur de coût le plus élevé qui maintient la latence de connexion sous votre seuil UX (typiquement 300ms–1s).
• Audits de sécurité : Coller un hash existant dans le parser pour vérifier qu'il utilise $2b$, confirmer que le facteur de coût respecte les minimums OWASP, et vérifier les longueurs correctes de sel et de hash.

Erreurs Courantes avec Bcrypt

• Utiliser un coût de 4–8 en production : Ces valeurs se complètent en moins de 1ms et n'offrent aucune résistance significative à la force brute. Le coût 4 n'existe que pour les tests unitaires. Utiliser au minimum le coût 10, et le coût 12 par défaut.
• Hacher des hashes déjà hachés : Exécuter bcrypt sur un hash bcrypt produit une chaîne doublement encodée qui ne pourra jamais être vérifiée. Toujours hacher uniquement le texte en clair original.
• Ignorer la limite de 72 octets : Bcrypt ne traite que les 72 premiers octets de toute entrée. Si votre application permet des mots de passe de plus de ~72 caractères ASCII, envisagez le pré-hachage avec SHA-256 avant bcrypt, ou passez à Argon2id qui n'a pas cette limite.

Questions Fréquentes

Quel facteur de coût utiliser pour bcrypt ?

OWASP recommande le facteur de coût 12 comme point de départ, visant environ 250ms par hash sur du matériel moderne. La valeur correcte dépend de votre serveur spécifique — utilisez le benchmark local sur cette page pour mesurer le temps réel, puis choisissez le facteur le plus élevé qui maintient la latence d'authentification sous votre seuil UX.

Un hash bcrypt peut-il être inversé ou déchiffré ?

Non. Bcrypt est une fonction à sens unique — il n'existe aucune méthode mathématique pour dériver le mot de passe original d'un hash. La seule approche est la force brute : deviner des mots de passe, hacher chacun avec le sel stocké et comparer. Le nombre élevé d'itérations rend cela computationnellement coûteux.

Quelle est la différence entre les préfixes $2a$ et $2b$ de bcrypt ?

$2a$ est la spécification originale de 1999. Certaines implémentations avaient un bug sur les cas limites avec des mots de passe contenant des caractères au-dessus de 8 bits. $2b$ corrige ce bug et est le standard actuel. $2y$ est une variante PHP mathématiquement équivalente à $2b$. Pour toute nouvelle implémentation, utiliser $2b$.

Bcrypt prend-il en charge les mots de passe de plus de 72 caractères ?

Bcrypt ne traite que les 72 premiers octets de toute entrée. Les caractères au-delà de 72 octets sont ignorés silencieusement. Si votre application permet des mots de passe plus longs, envisagez le pré-hachage avec SHA-256 avant bcrypt, ou passez à Argon2id qui n'a pas de limite de longueur.

Dois-je utiliser bcrypt ou Argon2id pour un nouveau projet ?

OWASP recommande désormais Argon2id comme premier choix pour les nouveaux systèmes — il est memory-hard (plus résistant aux attaques GPU et ASIC), sans limite de longueur de mot de passe, et a remporté le Password Hashing Competition en 2015. Bcrypt reste un choix solide pour les systèmes qui l'utilisent déjà, avec un facteur de coût de 12 ou plus.

Ressources

• OWASP Password Storage Cheat Sheet — Guide de référence sur les algorithmes recommandés, les facteurs de coût et les stratégies de migration.
• bcryptjs sur GitHub — La bibliothèque JavaScript pure qui alimente cet outil — aucune dépendance native, fonctionne dans n'importe quel navigateur.