Générateur et Vérificateur de Hash Bcrypt

Bienvenue sur le Générateur et Vérificateur de Hash Bcrypt — un outil en ligne gratuit qui vous permet de générer des hachages de mot de passe bcrypt cryptographiquement sécurisés avec un facteur de coût configurable et de vérifier si un mot de passe en texte brut correspond à un hachage bcrypt existant. Que vous initialisiez une base de données, déboguiez un flux de connexion, migriez des utilisateurs entre des systèmes ou appreniez le hachage adaptatif de mots de passe, cet outil vous donne des résultats instantanés ainsi qu'une décomposition visuelle éducative de la structure du format de hachage de 60 caractères de bcrypt.

Qu'est-ce que Bcrypt et pourquoi l'utiliser ?

Bcrypt est une fonction de hachage de mot de passe adaptative basée sur le chiffrement Blowfish, conçue en 1999 par Niels Provos et David Mazières. Contrairement aux hachages cryptographiques rapides tels que SHA-256 ou MD5, bcrypt est intentionnellement lent et inclut un facteur de coût réglable qui peut être augmenté à mesure que le matériel s'améliore. Chaque hachage bcrypt intègre également un sel aléatoire unique, ce qui empêche les attaquants d'utiliser des tables arc-en-ciel précalculées. L'OWASP recommande bcrypt comme l'un des quatre algorithmes de hachage de mot de passe acceptables pour stocker les identifiants utilisateur dans les applications web modernes.

Facteur de coût : le cœur de la sécurité Bcrypt

Le facteur de coût (également appelé facteur de travail ou tours) contrôle la complexité informatique du hachage. Il est logarithmique : chaque +1 double le travail. Un coût de 12 prend environ 250 millisecondes sur un CPU moderne typique ; un coût de 14 prend environ 1 seconde. Le tableau ci-dessous présente les temps de calcul estimés pour chaque niveau de coût — choisissez une valeur assez rapide pour votre flux de connexion mais assez lente pour décourager les attaquants.

Anatomie du hachage Bcrypt

Chaque hachage bcrypt mesure exactement 60 caractères et suit une structure fixe. Comprendre chaque segment facilite grandement le débogage des problèmes de connexion ou la migration des hachages entre systèmes :

Le sel et l'encodage du condensé

Bcrypt utilise un alphabet base64 personnalisé similaire au base64 standard mais utilise ./ au lieu de +/ et n'utilise pas de remplissage (padding). C'est purement historique et cela n'affecte pas la sécurité. Le sel est composé de 16 octets aléatoires, encodés sur 22 caractères base64 ; le condensé est de 23 octets, encodé sur 31 caractères.

Explication des variantes Bcrypt

Vous rencontrerez plusieurs préfixes bcrypt dans la nature. Tous produisent des hachages de même structure, mais ils ont des origines distinctes :

Comment utiliser cet outil

1. Choisir le mode : Sélectionnez Générer un hachage pour créer un nouveau hachage bcrypt, ou Vérifier le hachage pour vérifier si un mot de passe correspond à un hachage existant.
2. Saisir le mot de passe : Tapez le mot de passe en texte brut dans le champ de saisie. Le compteur d'octets vous avertit si votre mot de passe approche de la limite de 72 octets de bcrypt.
3. Régler le facteur de coût : En mode Générer, déplacez le curseur pour choisir un facteur de coût entre 4 et 15. Le temps de calcul estimé et l'évaluation de sécurité se mettent à jour en temps réel.
4. Coller le hachage à vérifier : En mode Vérifier, collez le hachage bcrypt de 60 caractères existant commençant par $2a$, $2b$, $2x$ ou $2y$.
5. Lancer et lire le résultat : Cliquez sur le bouton d'action. Le mode Générer renvoie le hachage avec une décomposition anatomique codée par couleur ; le mode Vérifier affiche un grand indicateur CORRESPONDANCE ou PAS DE CORRESPONDANCE avec le facteur de coût d'origine.

La limite de mot de passe de 72 octets

Bcrypt est basé sur la phase de configuration de clé de Blowfish, qui ne consomme que les 72 premiers octets du mot de passe. Les mots de passe de plus de 72 octets sont tronqués silencieusement par les anciennes bibliothèques ou purement rejetés par les nouvelles. Notez que ce sont les octets qui comptent, pas les caractères — un seul emoji pèse 4 octets, et la plupart des caractères non-ASCII prennent 2 à 4 octets en UTF-8. Si votre application accepte des mots de passe de longueur arbitraire, l'atténuation standard consiste à pré-hacher le mot de passe avec SHA-256 et à encoder le condensé en base64 avant de le passer à bcrypt ; cela produit une entrée fixe de 44 octets qui tient confortablement dans la limite.

Quand choisir Bcrypt vs Argon2 vs Scrypt

Les recommandations modernes de l'OWASP et de l'IETF (RFC 9106) listent quatre algorithmes acceptables : Argon2id (préféré pour les nouvelles applications), bcrypt, scrypt et PBKDF2. Choisissez bcrypt lorsque :

• Vous avez besoin d'une large compatibilité — chaque langage courant possède une bibliothèque bcrypt mature
• Vous travaillez avec un système existant qui utilise déjà bcrypt
• Vous voulez un algorithme éprouvé avec plus de 25 ans de cryptanalyse
• Le hachage exigeant en mémoire (Argon2id, scrypt) est impraticable pour votre environnement

Choisissez Argon2id si vous construisez un nouveau système sans contraintes de compatibilité — c'est le gagnant moderne de la Password Hashing Competition et il offre une résistance contre les attaques par GPU et FPGA que bcrypt ne peut égaler.

Cas d'utilisation pratiques

Pour les développeurs

• Initialisez des bases de données de développement avec des utilisateurs de test réalistes sans exécuter tout votre flux d'inscription
• Générez des données de test pour des tests d'intégration qui exercent le chemin de connexion
• Déboguez les échecs de connexion en vérifiant le hachage de production par rapport au mot de passe signalé par l'utilisateur
• Migrez les hachages $2a$ hérités vers $2b$ en effectuant un nouveau hachage lors de la prochaine connexion
• Ajustez le facteur de coût pour votre environnement de production en mesurant le temps de calcul réel

Pour les ingénieurs en sécurité

• Vérifiez qu'un service d'authentification tiers produit des hachages au facteur de coût qu'il prétend
• Auditez le stockage des mots de passe en inspectant la variante de hachage et le coût dans des échantillons de production
• Créez du matériel de formation montrant comment l'anatomie de bcrypt le rend résistant aux tables arc-en-ciel

Pour les apprenants

• Générez deux fois le même mot de passe pour voir comment le sel produit des hachages différents
• Expérimentez avec différents facteurs de coût pour ressentir l'effet de doublement de première main
• Vérifiez un hachage connu pour comprendre comment bcrypt extrait le coût et le sel avant de hacher le candidat

Foire aux questions

Quel facteur de coût dois-je utiliser pour bcrypt ?

L'OWASP recommande actuellement un facteur de coût d'au moins 10, 12 étant un bon réglage par défaut moderne qui prend environ 250 millisecondes sur un serveur typique. Le coût est logarithmique, donc chaque +1 double le travail. Un coût de 14 est approprié pour les applications à haute sécurité, tandis que 15 est le maximum pratique pour les connexions interactives. N'utilisez jamais un coût inférieur à 10 en production.

Quelle est la différence entre $2a$, $2b$, $2x$ et $2y$ ?

Toutes quatre sont des variantes de bcrypt distinguées par leur préfixe. $2a$ est la révision originale ; $2x$ et $2y$ étaient des correctifs PHP d'urgence pour un bug d'extension de signe découvert en 2011 ; $2b$ est l'implémentation de référence moderne qui a corrigé un bug de dépassement sur les mots de passe longs. Les hachages générés avec n'importe quelle variante restent vérifiables. Les bibliothèques modernes produisent $2b$ par défaut et vous devriez le préférer pour les nouveaux hachages.

Le mot de passe que je saisis est-il envoyé à un serveur ?

Le formulaire est traité côté serveur via HTTPS pour effectuer le calcul bcrypt, mais ni le mot de passe ni le hachage résultant ne sont enregistrés ou stockés — chaque requête est traitée puis supprimée. Pour une paranoïa absolue concernant les mots de passe de test, ne collez jamais un vrai mot de passe de production dans un outil en ligne. Utilisez cet outil avec des mots de passe de test jetables ou dans un environnement de développement local.

Pourquoi bcrypt a-t-il une limite de mot de passe de 72 octets ?

Bcrypt est basé sur la phase de configuration de clé de Blowfish, qui ne consomme que les 72 premiers octets de l'entrée. Les mots de passe de plus de 72 octets sont tronqués silencieusement par les anciennes bibliothèques ou rejetés par les plus récentes. Pour prendre en charge des mots de passe arbitrairement longs, pré-hachez avec SHA-256 et encodez le condensé en base64 avant de le passer à bcrypt. Cet outil vous avertit lorsque votre mot de passe dépasse la limite.

Puis-je vérifier un hachage généré par une autre bibliothèque bcrypt ?

Oui. Toutes les implémentations de bcrypt suivent le même format de transmission ($variant$cost$salt+digest, 60 caractères au total) et produisent des hachages interopérables. Un hachage créé par bcrypt Node.js, password_hash PHP, passlib Python, Spring Security ou toute bibliothèque conforme sera vérifié correctement ici, tant que le préfixe de variante est reconnu.

Pourquoi la génération deux fois du même mot de passe donne-t-elle un hachage différent ?

Bcrypt génère automatiquement un nouveau sel aléatoire de 16 octets pour chaque hachage. Le sel est mélangé à l'algorithme et intégré dans la sortie, de sorte que deux hachages du même mot de passe ne sont virtuellement jamais identiques. La vérification fonctionne car checkpw extrait le coût et le sel du hachage stocké et relance bcrypt avec ces paramètres exacts avant de comparer le condensé.

Puis-je récupérer le mot de passe original à partir d'un hachage bcrypt ?

Non. Bcrypt est une fonction unidirectionnelle — il n'y a pas d'opération de déchiffrement. La seule façon de trouver le mot de passe original à partir d'un hachage est de deviner des mots de passe et de les passer par bcrypt avec le même coût et le même sel jusqu'à ce que les condensés correspondent, ce qui est exactement ce que font les attaquants lors d'une attaque par force brute. Tout l'intérêt du coût adaptatif de bcrypt est de rendre ces tentatives prohibitvement coûteuses.

Cela fonctionne-t-il sur les appareils mobiles ?

Oui. L'interface est entièrement responsive et fonctionne sur smartphones, tablettes et ordinateurs de bureau. Le commutateur de mode, le curseur de coût et les panneaux de résultats s'adaptent tous aux écrans étroits.

Ressources additionnelles

• Bcrypt — Wikipédia
• A Future-Adaptable Password Scheme (Provos & Mazières, 1999)
• OWASP Password Storage Cheat Sheet
• RFC 9106 — Fonction Argon2 Memory-Hard (alternative à bcrypt)