Décodeur de hachage de mot de passe

Les hachages de mots de passe stockent les identifiants de manière sécurisée en utilisant des fonctions unidirectionnelles avec sel et facteur de coût configurable. Cet outil détecte automatiquement et analyse les hachages au format Modular Crypt Format (MCF), PHC String Format et schémas LDAP, montrant l'algorithme, les paramètres, le sel, la sortie de hachage et une évaluation de sécurité.

Specifications

• PHC String Format
• RFC 9106 - Argon2
• RFC 7914 - scrypt
• SHA-crypt specification
• OWASP Password Storage Cheat Sheet

Cas d'utilisation courants

• Identifier quel algorithme de hachage une base de données utilise pour les mots de passe
• Auditer la sécurité des hachages de mots de passe lors de tests de pénétration ou revues de sécurité
• Vérifier que les facteurs de coût bcrypt et les paramètres Argon2 respectent les recommandations OWASP
• Comprendre les schémas de stockage de mots de passe des annuaires LDAP
• Déboguer les problèmes d'authentification en inspectant le format et les paramètres du hachage

Fonctionnalites

• Détection automatique des formats MCF ($1$, $2b$, $5$, $6$, $sha1$, $apr1$), PHC ($argon2id$, $scrypt$, $pbkdf2$) et LDAP ({SSHA}, {SHA}, {MD5})
• Afficher l'algorithme, la variante, les paramètres (coût, tours, mémoire, parallélisme), le sel et la sortie de hachage
• Évaluation de sécurité : critique (MD5/non salé), faible (SHA-1/coût bas), modéré (SHA-crypt), fort (bcrypt 12+/argon2/scrypt)
• Recommandations d'évaluation de sécurité avec code couleur
• Affichage du format d'encodage du hachage (base64, hex, etc.)
• Analyser plusieurs hachages depuis une entrée multi-lignes
• Afficher la longueur en bits du hachage et le format d'encodage
• Lien vers les spécifications pertinentes pour chaque algorithme

Exemples

$2b$12$LJ3m4ys3Lg2VBe5E5Ij25eNsaDl3JK8i3pg7jBepGQhWcqMpqXA4q

$argon2id$v=19$m=65536,t=3,p=4$c29tZXNhbHQ$RdescudvJCsgt3ub+b+daw

Conseils

• Un facteur de coût bcrypt de 12+ est recommandé par OWASP. Chaque incrément double le temps de calcul.
• Argon2id est la meilleure pratique actuelle — il combine la résistance aux canaux auxiliaires (argon2i) et la résistance GPU (argon2d).
• LDAP {SSHA} est du SHA-1 salé — mieux que {SHA} mais toujours un hachage rapide. Migrez vers bcrypt ou Argon2.
• Collez la sortie du hachage de mot de passe du panneau Encoder pour le décoder et le vérifier ici.

Comprendre Décodeur de hachage de mot de passe

Password hashing is the practice of storing passwords as one-way cryptographic hashes rather than plaintext. When a user sets a password, the system hashes it and stores the hash. During login, the system hashes the submitted password and compares the result to the stored hash. Because the hash function is one-way, an attacker who obtains the hash database cannot directly recover the passwords.

Modern password hashing algorithms are intentionally slow and memory-intensive to resist brute-force attacks. bcrypt uses a configurable cost factor where each increment doubles the computation time. Argon2 (the winner of the 2015 Password Hashing Competition) adds configurable memory usage to resist GPU-based attacks. scrypt similarly requires significant memory. These "slow hashes" are fundamentally different from fast hashes (MD5, SHA-256) which are designed for speed and are unsuitable for password storage.

Password hashes use standardized string formats for portability. The Modular Crypt Format (MCF) uses $ delimiters: $2b$12$... for bcrypt, $5$ for SHA-256-crypt, $6$ for SHA-512-crypt. The PHC String Format (used by Argon2) adds named parameters: $argon2id$v=19$m=65536,t=3,p=4$salt$hash. LDAP systems use scheme prefixes: {SSHA}, {PBKDF2}.

Each hash includes a salt — random data combined with the password before hashing to ensure that identical passwords produce different hashes. Without salting, attackers can use precomputed rainbow tables to look up common password hashes instantly. The salt is stored alongside the hash (it is not secret) and is generated randomly for each password.

For new applications, Argon2id is the current best practice as recommended by OWASP. If Argon2 is not available in your framework, bcrypt with cost factor 12+ is the next best choice, and scrypt is also acceptable. MD5, SHA-1, and plain SHA-256 should never be used for passwords — they are too fast and can be brute-forced at billions of attempts per second on modern GPUs. MD5 in particular was designed as a fast checksum algorithm, not for password storage, and it has known collision vulnerabilities. Unsalted MD5 hashes are also vulnerable to rainbow table attacks.

The bcrypt cost factor (the number after $2b$) is an exponent that controls computation time. Cost 10 means 2^10 = 1,024 iterations, while cost 12 means 2^12 = 4,096 iterations — four times slower than cost 10. OWASP recommends cost 12 as the minimum. Each increment doubles the time, so increasing from 10 to 12 makes hashing 4x slower for both the server and any attacker.

A salt and a pepper serve different roles in password security. A salt is random data stored alongside the hash, unique per password, ensuring identical passwords produce different hashes — salts are not secret. A pepper is a secret key applied to all passwords (typically via HMAC), stored separately from the database in application configuration or a hardware security module. If the database is compromised but the pepper is not, the attacker cannot crack the hashes even with the salts. Using both provides defense in depth.