bcrypt Générateur de Hachage

Outil en ligne gratuit bcrypt Générateur de Hachage. Traitement 100% local — vos données ne quittent jamais votre appareil.

General
Password Hashing / KDF
Specialized
Deprecated
Sortie

Le résultat sera affiché ici...

Entrée → Calculer le hachage

Usage Guide

À propos de bcrypt

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. Elle a été spécifiquement construite pour être lente et coûteuse en calcul, rendant les attaques par force brute impraticables. bcrypt est l'un des algorithmes de hachage de mots de passe les plus largement déployés dans le monde, supporté nativement par des frameworks comme Rails, Django, Laravel et Node.js (bcryptjs). Chaque hash bcrypt intègre un sel aléatoire et le facteur de coût, de sorte que le hash est entièrement autonome pour la vérification.

Standard Éprouvé : bcrypt est en usage en production depuis plus de 25 ans et reste un choix fiable pour le stockage des mots de passe. L'OWASP recommande un facteur de coût minimum de 10, avec cost=12 comme référence 2023. Pour les nouveaux projets, Argon2id est préféré ; bcrypt reste entièrement fiable pour les systèmes existants.

Étapes d'utilisation

Cet outil supporte deux opérations : hacher un mot de passe (Chiffrer) et vérifier un mot de passe contre un hash (Déchiffrer) :

•
1. Mode Hash (Chiffrer)Sélectionnez le mode 'Chiffrer', entrez le mot de passe dans la zone de saisie, puis cliquez sur 'Calculer le Hash'
•
2. Obtenir le HashLa sortie est une chaîne bcrypt de 60 caractères comme $2b$12$... — copiez-la et stockez-la dans votre base de données
•
3. Mode Vérification (Déchiffrer)Sélectionnez le mode 'Déchiffrer', entrez motdepasse|$2b$12$... (séparé par un pipe) dans la zone de saisie, puis cliquez sur 'Déchiffrer'
•
4. Vérifier le RésultatL'outil retourne '✓ Password matches' si le mot de passe est correct, ou un message d'erreur s'il ne correspond pas
Protection de la Confidentialité : Tous les calculs bcrypt s'exécutent entièrement dans votre navigateur en utilisant WebAssembly. Aucune donnée n'est jamais envoyée à un serveur — traitement complètement hors ligne.

Caractéristiques de l'Algorithme

bcrypt possède plusieurs propriétés qui le rendent bien adapté au stockage des mots de passe :

•
Intentionnellement LentL'ordonnancement des clés Blowfish est coûteux à calculer, rendant chaque tentative de hash lente et les attaques par force brute coûteuses
•
Sel IntégréChaque hash inclut un sel aléatoire unique de 128 bits, prévenant les attaques par tables arc-en-ciel et par mots de passe identiques
•
Facteur de Coût AjustableLe facteur de coût (4–31) contrôle le travail : chaque incrément double le temps de calcul, vous permettant de rester au rythme des améliorations matérielles
•
Résistance au GPULes modèles d'accès mémoire de l'ordonnancement des clés Blowfish limitent le parallélisme GPU comparé à des fonctions de hachage plus simples comme MD5 ou SHA-256
•
Hash AutonomeLa sortie de 60 caractères ($2b$12$[22-char sel][31-char hash]) inclut tous les paramètres nécessaires à la vérification — aucune métadonnée supplémentaire requise
Limitation vs Argon2 : bcrypt n'utilise que ~4 Ko de mémoire pendant le calcul, le rendant significativement moins résistant aux attaques ASIC et matériel personnalisé que Argon2, qui nécessite des mégaoctets de mémoire. Pour les nouveaux projets, préférez Argon2id. bcrypt reste approprié pour maintenir les systèmes existants.

Guide du Facteur de Coût

Choisir le bon facteur de coût équilibre la sécurité et les performances du serveur :

•
Coût 10Minimum OWASP (2023). ~100 ms sur un serveur moderne. Acceptable pour les sites à faible trafic ou les environnements à ressources limitées
•
Coût 12Recommandation de référence OWASP 2023. ~400 ms. Bon équilibre sécurité/performance pour la plupart des applications web
•
Coût 14~1,5 s. Haute sécurité pour les applications sensibles (finance, santé). Peut nécessiter un traitement asynchrone pour éviter le blocage de l'UI
•
Coût 31 (max)Maximum théorique — le calcul prend des heures. Ne jamais utiliser en production ; uniquement pour l'archivage hors ligne ou les démonstrations
Conseil d'Optimisation : Faites des benchmarks sur votre matériel de production et visez 200–500 ms par hash. À mesure que les CPU s'améliorent au fil des années, incrémentez le facteur de coût pour maintenir le même temps d'horloge. Les nouveaux hashes peuvent utiliser le coût mis à jour ; les hashes existants restent vérifiables car le coût est stocké dans la chaîne hash elle-même.

FAQ

Q: Quel est le format de sortie de bcrypt ?

A: Un hash bcrypt fait toujours exactement 60 caractères et ressemble à : $2b$12$LQv3c1yqBWVHxkd0LHAkCOYz6TtxMQJqhN8/lewdBdXyXu2zXpOme.
Décomposition :
$2b$ : Identifiant de version bcrypt.
12$ : Le facteur de coût.
22 caractères suivants : Sel aléatoire de 128 bits encodé en Base64.
31 derniers caractères : Hash dérivé de 184 bits encodé en Base64.
Propriété clé : Tous les paramètres sont incorporés dans la chaîne — aucun stockage supplémentaire n'est nécessaire pour vérifier un mot de passe ultérieurement.

Q: Comment bcrypt se compare-t-il à Argon2 ?

A: bcrypt (1999) : difficile en calcul, ~4 Ko mémoire, résistance GPU modérée, support universel. Argon2 (2015) : difficile en mémoire (configurable, 64 Mo par défaut), résistance ASIC/GPU beaucoup plus forte, préféré par OWASP et NIST. Quand utiliser bcrypt : Maintenance d'un système existant ou quand Argon2 n'est pas encore disponible. Quand utiliser Argon2 : Tous les nouveaux projets.

Q: Pourquoi bcrypt ne peut-il pas être utilisé pour hacher des fichiers ou de grandes données ?

A: bcrypt a une limite d'entrée de 72 octets. Les caractères au-delà du 72e octet sont silencieusement ignorés. Pour l'intégrité des fichiers, utilisez SHA-256 ou SHA-512. bcrypt est conçu spécifiquement pour les mots de passe courts saisis manuellement uniquement.

Q: bcrypt est-il sûr si ma base de données est compromise ?

A: Oui — un hash bcrypt est unidirectionnel. Avec cost=12, un seul cœur CPU peut tenter environ 2–5 hashes par seconde, rendant les attaques exhaustives contre des mots de passe forts effectivement infaisables. Cependant, bcrypt ne protège pas les mots de passe faibles — appliquez toujours une politique de force minimale de mot de passe.

Q: Quel facteur de coût dois-je utiliser en production ?

A: Recommandation OWASP 2023 : cost=12 comme référence. Faites des benchmarks sur votre serveur de production et choisissez le facteur de coût le plus élevé qui maintient le hachage sous 500 ms. Ne descendez jamais en dessous de cost=10. Réévaluez tous les 2–3 ans à mesure que le matériel s'améliore.

Q: bcrypt peut-il être utilisé pour le stockage de clés API ou de tokens ?

A: Oui, avec des mises en garde. bcrypt convient pour hacher les clés API et tokens de moins de 72 octets et vérifiés rarement. Pour la vérification haute fréquence, utilisez plutôt une approche rapide SHA-256 + sel.

Use Cases

Recommandé : Stockage de Mots de Passe Utilisateur

C'est le cas d'usage principal de bcrypt. Hachez avec bcrypt (cost ≥ 12) et stockez la chaîne de 60 caractères. Lors de la connexion, exécutez la vérification bcrypt. bcrypt est supporté nativement dans Rails (has_secure_password), Django, Laravel et Node.js (bcryptjs).

Recommended Configuration:
  • ✅ bcrypt (cost ≥ 12, largement supporté — recommandé pour les systèmes existants)
  • ✅ Argon2id (préféré pour les nouveaux projets)
  • PBKDF2-SHA256 (≥ 600k itérations, environnements conformes FIPS)
  • ❌ Ne pas utiliser SHA-256, MD5 ou autres hachages à usage général pour les mots de passe
Recommandé : Compatibilité avec les Systèmes Hérités

Pour les systèmes stockant des millions de hashes bcrypt, continuez d'utiliser bcrypt et augmentez le facteur de coût à mesure que le matériel s'améliore. Les nouveaux utilisateurs peuvent passer de manière transparente à Argon2id tandis que les hashes bcrypt (identifiés par le préfixe $2b$) continuent de se vérifier correctement.

Recommended Configuration:
  • ✅ Conserver bcrypt pour les hashes existants — aucune migration forcée requise
  • ✅ Introduire progressivement Argon2id pour les nouveaux mots de passe et mis à jour
  • ✅ Utiliser la détection de préfixe de hash ($2b$ vs $argon2id$) pour router la vérification
  • 💡 Journaliser l'algorithme utilisé par utilisateur pour suivre la progression de la migration
Acceptable : Hachage de Clés API

bcrypt peut hacher les clés API avant le stockage en base de données. Pour la vérification par requête à grande échelle, préférez un schéma HMAC-SHA256 rapide ou un hash SHA-256 de la clé.

Recommended Configuration:
  • ✅ bcrypt (cost=10–12, bon pour la vérification à basse fréquence)
  • ✅ SHA-256 + sel (plus rapide, adapté aux clés à haute entropie)
  • ✅ HMAC-SHA256 (pour la signature de tokens par requête)
  • 💡 Utiliser un préfixe de hash (8 premiers caractères) comme index de base de données pour une recherche rapide
Non Recommandé : Chiffrement de Fichiers ou de Données

bcrypt est une fonction de hachage unidirectionnelle, pas un algorithme de chiffrement. Il ne peut pas chiffrer des fichiers. De plus, la limite d'entrée de 72 octets de bcrypt le rend inadapté au hachage de contenus de fichiers. Pour le chiffrement de fichiers, utilisez un chiffrement symétrique (ex., AES-256-GCM).

Recommended Configuration:
  • ❌ Ne pas utiliser bcrypt pour le chiffrement de fichiers (non réversible)
  • ❌ Ne pas hacher des données de plus de 72 octets avec bcrypt
  • ✅ Utiliser AES-256-GCM pour le chiffrement symétrique de fichiers
  • ✅ Utiliser Argon2id ou scrypt pour la dérivation de clés basée sur mot de passe
Non Recommandé : Hachage Général de Données

bcrypt est trop lent pour les vérifications d'intégrité de données à usage général. Utilisez SHA-256 ou SHA-512 pour la vérification d'intégrité.

Recommended Configuration:
  • ❌ Ne pas utiliser bcrypt pour les vérifications d'intégrité de données ou le hachage de contenu
  • ✅ SHA-256 (hachage d'intégrité à usage général)
  • ✅ BLAKE2b (hachage cryptographique haute vitesse)
  • ✅ SHA-3 / SHA-512 (marge de sécurité plus élevée)
Non Recommandé : Authentification Haute Fréquence

bcrypt est conçu pour être lent (~200–500 ms à cost=12). L'exécuter sur chaque requête API mettrait votre serveur à genoux. Utilisez bcrypt une seule fois à la connexion — puis émettez un JWT signé pour les requêtes suivantes.

Recommended Configuration:
  • ❌ Ne pas exécuter bcrypt sur chaque requête API
  • ✅ JWT + HMAC-SHA256 (auth stateless, rapide par requête)
  • ✅ Session + Cookie (gestion de session traditionnelle côté serveur)
  • ✅ OAuth 2.0 / OpenID Connect (identité fédérée, basée sur les tokens)

Résumé des Bonnes Pratiques

  • Utiliser bcrypt (cost ≥ 12) pour le stockage des mots de passe utilisateur dans les systèmes existants. Pour les nouveaux projets, préférer Argon2id.
  • Ne jamais utiliser bcrypt pour le hachage général de données, le chiffrement de fichiers ou des données de plus de 72 octets.
  • Faire des benchmarks sur le matériel de production et viser 200–500 ms par hash. Incrémenter le facteur de coût tous les 2–3 ans.
  • Pour les scénarios d'auth haute fréquence, utiliser bcrypt uniquement à la connexion, puis émettre des JWT ou des tokens de session.
  • Migration progressive de bcrypt vers Argon2id : conserver bcrypt pour les hashes existants, utiliser Argon2id pour les nouveaux mots de passe.

Discussion et commentaires

0 commentaires
Moi