Password Hashing Guide
Password storage needs slow, salted, tunable password hashing. Plain MD5, SHA-1, SHA-256, or SHA-512 are too fast and are not designed for password databases.
Why Plain SHA-256 Is Not Enough
Fast hashes help attackers test billions of guesses. Password hashing raises attack cost with salts, iteration work, and in modern algorithms, memory pressure.
Salt, Pepper, Cost, Memory
Use a unique random salt per password. A pepper is a separate server-side secret. Cost and memory settings should be tuned against your login latency and hardware budget, starting from current OWASP or platform guidance rather than demo defaults.
| Algorithm | Strength | Tuning | Limit | Best Fit |
|---|---|---|---|---|
| Argon2id | Modern default | Memory and iterations | Good side-channel balance | New password storage |
| bcrypt | Very broad support | Cost factor | 72-byte password limit | Compatibility and mature stacks |
| scrypt | Memory-hard | N, r, p parameters | More complex tuning | Systems that already support scrypt |
| PBKDF2 | Standards and FIPS contexts | Iteration count | Not memory-hard | Compliance or legacy requirements |
Do not enter real production passwords into browser tools. Generate fixtures here; hash real passwords on your server.
Generate Test Hashes
Use the password hash generator for fixtures and parameter exploration. Its browser defaults are intentionally small enough for demos and are not production recommendations.
Argon2id Details
Review the dedicated Argon2id page for options and security boundaries.