Password Hashing — BCrypt vs Argon2
Fast recall
Quick revision
Core answer
{bcrypt}..., {argon2}...) and enables transparent migration on next login.Whether the candidate understands why general-purpose hash functions (MD5, SHA-256) are inappropriate for passwords and what makes a password hashing function secure.
Suggesting SHA-256 with a salt as sufficient for password storage — it is orders of magnitude faster than BCrypt and vulnerable to GPU attacks.
Mention the importance of cost factor tuning to target ~100ms hash time, how DelegatingPasswordEncoder handles algorithm migration, and the risk of pepper vs salt.
Interview-ready guide
Interview answer
Why fast hashes fail for passwords
- SHA-256: ~10B hashes/sec on a consumer GPU
- 8-char password: ~200T combinations — crackable in hours with dictionary attacks
- BCrypt cost 12: ~100ms/hash -> 10/sec/GPU -> decades for the same space
BCrypt
- Configurable work factor:
new BCryptPasswordEncoder(12) - Each +1 doubles compute time; tune to ~100ms
- Random salt automatic — no two BCrypt hashes of the same password match
- 72-byte limit; truncation is silent
Argon2id — modern choice
- 2015 Password Hashing Competition winner
- OWASP recommendation (2023+)
- Memory-hard — beats GPU farms
- Three params: memory (64MB+), iterations (3), parallelism (2)
Argon2PasswordEncoder.defaultsForSpringSecurity_v5_8()
Migration without breaking logins
DelegatingPasswordEncoderprefixes hashes:{bcrypt}$2a$12$...or{argon2}$argon2id$...- Old BCrypt hashes verify correctly; new passwords use current default
- Implement
UserDetailsPasswordService.updatePasswordfor transparent re-hashing on login - After migration, disable old algorithm in the encoder map
Operational rules
- Always inject
PasswordEncoderas a bean — never compare hashes manually - Use
encoder.matches(raw, hash); never re-encode for comparison - Salt is automatic; pepper (app-wide secret) is optional defense-in-depth
- Revisit cost factors yearly as hardware improves
Recommendation for 2026
- New apps: Argon2id default, BCrypt fallback
- Existing apps: keep BCrypt cost 12+, plan transparent migration to Argon2
Password Hashing — BCrypt vs Argon2
Direct Answer
Passwords must never be stored in plaintext or reversibly encrypted — only one-way adaptive hashing functions designed for passwords. BCrypt (1999) is the widely-deployed standard with a configurable cost factor. Argon2id is the 2015 PHC winner, OWASP-recommended, with memory-hardness that makes GPU attacks economically impractical. Spring Security's PasswordEncoder abstraction supports both via DelegatingPasswordEncoder, which prefixes hashes with the algorithm ({bcrypt}..., {argon2}...) and enables transparent migration on next login.
Common Mistakes & Pitfalls
Suggesting SHA-256 with a salt as sufficient for password storage — it is orders of magnitude faster than BCrypt and vulnerable to GPU attacks.
Check your understanding
Answer these without looking back at the article.
- What is the difference between a salt and a pepper, and which is more important?
- How does Spring Security's DelegatingPasswordEncoder handle migrating from BCrypt to Argon2?
- Why is bcrypt's 72-byte password truncation a potential security concern?
- How would you tune Argon2id memory and iteration parameters for a high-traffic login endpoint?
Related interview prep categories
2Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.