PBKDF2 ships with the JDK, so why pull in a library for bcrypt, scrypt, or Argon2, and how do you use them on the JVM?

## Why PBKDF2 alone is not the end of the story PBKDF2 makes guessing slow by repeating a hash many times - it burns **CPU time**. That's good, but it has a weakness: it needs almost **no memory**. Attackers don't crack passwords on normal CPUs; they use **GPUs** (thousands of parallel cores) and custom **ASICs**/FPGAs. Because PBKDF2 is tiny in memory, you can run tens of thousands of PBKDF2 computations in parallel on one cheap card. So PBKDF2 raises cost less than you'd hope against a serious attacker. ## Memory-hardness: the next lever The fix is to make each guess require a lot of **RAM**, not just CPU. RAM is expensive and hard to parallelize cheaply on a GPU/ASIC, so a **memory-hard** KDF narrows the gap between your server and the attacker's hardware. The main families: - **bcrypt** (1999) - based on the Blowfish key schedule, has a built-in salt and a `cost`/work factor. It uses a fixed, modest amount of memory (4 KB), so it's *somewhat* GPU-resistant but not strongly memory-hard. It also silently truncates passwords beyond 72 bytes - a real gotcha. Still a solid, battle-tested choice. - **scrypt** (2009) - explicitly memory-hard with tunable parameters `N` (CPU/memory cost), `r` (block size), `p` (parallelism). Much harder to attack on GPUs than PBKDF2/bcrypt. - **Argon2** (2015) - winner of the **Password Hashing Competition**, the modern recommendation. Tunable **memory**, **iterations (time)**, and **parallelism**. Three variants: **Argon2d** (max GPU resistance, but data-dependent memory access -> side-channel risk), **Argon2i** (side-channel resistant), and **Argon2id** (a hybrid - the recommended default). ## Why a library at all The **JDK/JCA only ships PBKDF2** (`SecretKeyFactory` with `PBKDF2WithHmac*`). There is no built-in bcrypt, scrypt, or Argon2. To use those you add a dependency. Common JVM options: - **Spring Security crypto** - the most ergonomic. It defines a `PasswordEncoder` interface with `encode(rawPassword)` and `matches(raw, encoded)`. Implementations: `BCryptPasswordEncoder`, `SCryptPasswordEncoder`, `Argon2PasswordEncoder`, `Pbkdf2PasswordEncoder`. - **`DelegatingPasswordEncoder`** - wraps several encoders and writes a scheme prefix into every hash, like `{argon2}$argon2id$v=19$m=...` or `{bcrypt}$2a$10$...`. On `matches`, it reads the prefix and dispatches to the right encoder. This is what makes **algorithm migration** painless: set your default to `{argon2}`, keep the old encoders registered to verify legacy hashes, and rehash on successful login. - **jBCrypt** / **Bouncy Castle** - lower-level libraries that Spring (and others) build on; Bouncy Castle provides Argon2 and scrypt primitives directly. ## How you actually call it (Spring Security example) ``` PasswordEncoder enc = PasswordEncoderFactories.createDelegatingPasswordEncoder(); String stored = enc.encode(rawPassword); // {argon2}$argon2id$... boolean ok = enc.matches(rawPassword, stored); if (ok && enc.upgradeEncoding(stored)) { /* rehash with stronger params */ } ``` `encode` salts and hashes (the salt is embedded in the output string), `matches` verifies in constant time, and `upgradeEncoding` tells you when a stored hash uses outdated parameters so you can rehash. ## Choosing - New system: **Argon2id**, sized so one hash takes ~tens of ms with a meaningful memory cost (e.g. tens of MB). - Can't add Argon2 (e.g. **FIPS** environments often mandate PBKDF2): use **PBKDF2WithHmacSHA256/512** with a high iteration count - it's the only NIST-approved one of the group. - Legacy/widely-portable: bcrypt is fine, mind the 72-byte truncation. The key interview point: PBKDF2 is *adequate* and built-in; memory-hard KDFs are *better* against modern cracking hardware, and you reach them through a library, ideally behind `PasswordEncoder` + `DelegatingPasswordEncoder` so you can migrate.