Password Hash Generator
Generate and verify secure password hashes using industry-standard algorithms. Configure parameters to balance security and performance for your application.
Winner of Password Hashing Competition (2015). Best choice for most applications.
Algorithm Parameters
A cryptographically secure random salt will be generated automatically.
100% Client-Side
All hashing happens in your browser. Your password is never sent to any server.
Table of Contents
What is Password Hashing?
Password hashing is the process of converting a password into a fixed-length string using a one-way cryptographic function. Unlike encryption, hashing cannot be reversed — you cannot recover the original password from its hash.
Password hashing is NOT the same as general-purpose hashing. Algorithms like MD5 and SHA-256 are designed to be fast, which makes them unsuitable for password storage. Password hashing algorithms like Argon2, bcrypt, scrypt, and PBKDF2 are intentionally slow and memory-intensive to resist brute-force attacks.
| Feature | General Hash (SHA-256) | Password Hash (Argon2) |
|---|---|---|
| Speed | Very fast (millions/sec) | Intentionally slow |
| Memory usage | Minimal | Configurable (MB to GB) |
| Salt handling | Manual | Built-in |
| GPU resistance | None | High (memory-hard) |
| Use case | Checksums, integrity | Password storage |
Algorithm Comparison
| Algorithm | Year | Memory-Hard | GPU Resistant | Recommendation |
|---|---|---|---|---|
| Argon2id | 2015 | ✅ Yes | ✅ Excellent | Best Choice |
| bcrypt | 1999 | ❌ No | ⚠️ Moderate | Good (Legacy) |
| scrypt | 2009 | ✅ Yes | ✅ Good | Good Alternative |
| PBKDF2 | 2000 | ❌ No | ❌ Poor | Use High Iterations |
Argon2id
Winner of the Password Hashing Competition (2015). Combines resistance to both side-channel and GPU attacks. The recommended choice for new applications.
bcrypt
Time-tested since 1999. Limited to 72-byte passwords. Still secure when properly configured but lacks memory-hardness.
scrypt
Memory-hard design makes GPU attacks expensive. Good choice when Argon2 is unavailable. Used by Litecoin.
PBKDF2
NIST-approved standard. Requires very high iteration counts (600K+) for adequate security. Vulnerable to GPU attacks.
Argon2id Deep Dive
Argon2 has three variants: Argon2d (data-dependent), Argon2i (data-independent), and Argon2id (hybrid). Argon2id is recommended as it provides the best balance of security properties.
Parameters Explained
- Memory (m): Amount of RAM used during hashing. Higher = more GPU-resistant. OWASP recommends at least 19 MB.
- Iterations (t): Number of passes over the memory. Higher = slower but more secure.
- Parallelism (p): Number of parallel threads. Should match available CPU cores.
- Hash Length: Output size in bytes. 32 bytes (256 bits) is standard.
OWASP Recommendations
OWASP recommends these minimum parameters for Argon2id:
- Memory: 19,456 KB (19 MB)
- Iterations: 2
- Parallelism: 1
For higher security, increase memory to 64 MB or more if your system allows it.
Choosing Parameters
The goal is to make hashing slow enough to resist attacks but fast enough to not impact user experience. Aim for 0.5-1 second per hash on your production hardware.
For Argon2id
- Set parallelism to match your CPU cores (typically 1-4 for web servers)
- Use at least 19 MB memory (OWASP minimum)
- Start with 2 iterations and increase until hashing takes ~1 second
For bcrypt
Use cost factor 10-12 for most web applications. Each increment doubles the work.
For scrypt
N=16384, r=8, p=1 is a common starting point. Increase N for more security.
For PBKDF2
OWASP recommends 600,000 iterations for PBKDF2-HMAC-SHA256. Use 210,000 for SHA-512.
Best Practices
- Always use Argon2id for new applications — it's the current best practice
- Never use MD5, SHA-1, or plain SHA-256 for passwords — they're too fast
- Always use unique, random salts — most password hashing libraries handle this automatically
- Store the full hash output — it contains the salt and parameters needed for verification
- Tune parameters for ~1 second execution time — balance security and UX
- Re-hash passwords on login when parameters change — upgrade security over time
- Use constant-time comparison — prevent timing attacks when verifying
- Consider pepper — an additional server-side secret for defense in depth
Frequently Asked Questions
Use Argon2id for new applications. It won the Password Hashing Competition and provides the best security. If Argon2 is unavailable, use bcrypt or scrypt. Only use PBKDF2 if required for compliance (e.g., FIPS).
SHA-256 is designed to be fast — modern GPUs can compute billions of hashes per second. This makes brute-force attacks trivial. Password hashing algorithms like Argon2 are intentionally slow and memory-intensive to resist such attacks.
A salt is random data added to the password before hashing. It ensures that identical passwords produce different hashes, preventing rainbow table attacks and making it impossible to tell if two users have the same password.
bcrypt's internal design limits input to 72 bytes. Passwords longer than this are silently truncated. For very long passwords, consider using Argon2id or pre-hashing with SHA-256 before bcrypt (though this adds complexity).
Password hashing libraries include verify functions that extract the salt and parameters from the stored hash, re-hash the input password with those same values, and compare the results using constant-time comparison. Never implement verification manually.
Yes. All hashing happens entirely in your browser using WebAssembly. Your password is never transmitted to any server. However, this tool is for testing and education — use proper libraries in your production code.
Argon2d is optimized against GPU attacks but vulnerable to side-channel attacks. Argon2i is resistant to side-channel attacks but less resistant to GPU attacks. Argon2id combines both approaches and is the recommended variant for password hashing.