Password Hash Decoder

Password hashes store credentials securely using one-way functions with salts and configurable work factors. This tool auto-detects and parses hashes in Modular Crypt Format (MCF), PHC String Format, and LDAP schemes, showing the algorithm, parameters, salt, hash output, and a security assessment.

Specifications

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

Common Use Cases

• Identify which hashing algorithm a database uses for passwords
• Audit password hash security during penetration tests or security reviews
• Verify bcrypt cost factors and Argon2 parameters meet OWASP recommendations
• Understand LDAP directory password storage schemes
• Debug authentication issues by inspecting hash format and parameters

Features

• Auto-detect MCF ($1$, $2b$, $5$, $6$, $sha1$, $apr1$), PHC ($argon2id$, $scrypt$, $pbkdf2$), and LDAP ({SSHA}, {SHA}, {MD5}) formats
• Display algorithm, variant, parameters (cost, rounds, memory, parallelism), salt, and hash output
• Security assessment: critical (MD5/unsalted), weak (SHA-1/low cost), moderate (SHA-crypt), strong (bcrypt 12+/argon2/scrypt)
• Color-coded security assessment recommendations
• Hash encoding format display (base64, hex, etc.)
• Parse multiple hashes from multi-line input
• Show hash bit length and encoding format
• Link to relevant specifications for each algorithm

Examples

$2b$12$LJ3m4ys3Lg2VBe5E5Ij25eNsaDl3JK8i3pg7jBepGQhWcqMpqXA4q

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

Tips

• bcrypt cost factor 12+ is recommended by OWASP. Each increment doubles computation time.
• Argon2id is the current best practice — it combines side-channel resistance (argon2i) and GPU resistance (argon2d).
• LDAP {SSHA} is salted SHA-1 — better than {SHA} but still a fast hash. Migrate to bcrypt or Argon2.
• Paste the output of password hashing from the Encode As panel to decode and verify it here.

Understanding Password Hash

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.