A quick reference for choosing a password hashing algorithm — what each one is, and when to reach for it.
Winner of the 2015 Password Hashing Competition. Tunable for both memory and CPU cost, which makes it resistant to GPU/ASIC cracking attempts far more effectively than CPU-only algorithms. OWASP's current guidance names Argon2id as the first choice for new systems where it's available.
OWASP minimum: 19 MiB memory (m=19456), 2 iterations, parallelism 1 · Try the Argon2 generator
Based on the Blowfish cipher, from 1999. Extremely well-established with decades of real-world scrutiny, and available in essentially every language/framework. Its main limitation is a fixed, relatively small memory cost, which makes it somewhat more GPU-crackable than Argon2 or scrypt at equivalent settings — still considered acceptable, just not the top pick for new systems. Watch out for its input limit: only the first 72 bytes of a password are used, and anything longer is silently ignored.
OWASP minimum: cost factor 10 · Try the bcrypt generator
Designed specifically to be expensive in both CPU and memory, originally for the Tarsnap backup service. A solid choice, though Argon2 is generally preferred for new systems since it won the dedicated password-hashing competition scrypt predates.
OWASP minimum: N=217 (131072), r=8, p=1, which needs about 128 MiB of memory · Try the scrypt calculator
The oldest of the four (RFC 2898, year 2000). Uses only CPU cost (no memory hardness), making it the most GPU/ASIC-crackable of the group at equivalent iteration counts — but it's the only one with FIPS 140 validation available, which matters for some compliance requirements. If you must use PBKDF2, use a high iteration count (600,000+ with SHA-256, per current OWASP guidance) and prefer Argon2/bcrypt/scrypt if you have the choice.
OWASP minimum: 600,000 iterations with SHA-256, or 210,000 with SHA-512 · Try the PBKDF2 calculator
General-purpose hashes are designed to be fast, which is exactly wrong for passwords: a single graphics card can try tens of billions of MD5 or SHA-256 guesses a second. Adding a salt stops precomputed tables but doesn't slow guessing down. These are fine for checksums and file verification, but a password database stored this way can be cracked wholesale if it leaks. If you find one, migrate it by rehashing each password with Argon2id the next time its owner logs in.
This is general orientation, not a substitute for your own threat model or current official guidance (OWASP's Password Storage Cheat Sheet is the standard reference, and is updated periodically) — always check current recommendations before choosing parameters for a real system.