How do you derive a PBKDF2 hash of a password in Java using SecretKeyFactory and PBEKeySpec?

## What problem this solves When you store user passwords, you must never store the plaintext. Instead you store a one-way transformation so that even if your database leaks, attackers can't trivially recover passwords. A plain hash (like a single SHA-256) is too fast: an attacker with the leaked hashes can try billions of guesses per second on a GPU. A **password-based key derivation function (KDF)** like **PBKDF2** deliberately makes each guess slow and adds a per-user random value (a **salt**), so attackers can't reuse work across users or precompute tables. ## The Java building blocks (JCA) Java's cryptography lives in the **JCA/JCE** (Java Cryptography Architecture / Extension). PBKDF2 is exposed through two classes: - **`SecretKeyFactory`** — a factory you obtain by *algorithm name*, e.g. `SecretKeyFactory.getInstance("PBKDF2WithHmacSHA256")`. The string names the PBKDF2 construction using HMAC-SHA-256 as its internal pseudo-random function (PRF). Other valid names: `PBKDF2WithHmacSHA512`, and the legacy `PBKDF2WithHmacSHA1` (avoid it). - **`PBEKeySpec`** — a *key specification* ("PBE" = password-based encryption) that bundles the four inputs PBKDF2 needs: `new PBEKeySpec(char[] password, byte[] salt, int iterationCount, int keyLength)`. Note `keyLength` is in **bits**, not bytes. ## The four inputs, defined 1. **password** — a `char[]`, deliberately not a `String`. `String`s are immutable and live in memory (and the string pool) until garbage-collected, so you can't reliably erase them. A `char[]` can be zeroed. 2. **salt** — random bytes unique per password, generated with `SecureRandom`. 16 bytes is standard. The salt is *not secret*; you store it alongside the hash. Its job is to make identical passwords hash differently and to defeat precomputed (rainbow) tables. 3. **iterationCount** — the **work factor**: how many times the internal PRF is applied. Higher = slower = more attacker cost. As of the mid-2020s, OWASP guidance is on the order of hundreds of thousands of iterations for SHA-256; you tune it to your hardware (aim for tens to ~100 ms per hash). 4. **keyLength** (bits) — how many output bits to produce; 256 (32 bytes) matched to the PRF is sensible. ## The call sequence ``` SecretKeyFactory f = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA256"); PBEKeySpec spec = new PBEKeySpec(password, salt, 600_000, 256); byte[] hash = f.generateSecret(spec).getEncoded(); spec.clearPassword(); ``` `generateSecret` runs PBKDF2 and returns a `SecretKey`; `getEncoded()` extracts the raw derived bytes. `clearPassword()` wipes the internal copy of the char[]. ## What you persist You must store everything needed to recompute the hash at login time **except the password itself**: the **salt**, the **iteration count**, the **algorithm**, and the **derived hash**. A common format encodes them together, e.g. `algorithm$iterations$base64(salt)$base64(hash)`. Storing the iteration count lets you raise the work factor over time without breaking old hashes. ## Verification To check a login, read the stored salt + iterations, derive the hash of the entered password with the *same* parameters, and compare. Compare with a **constant-time** comparison (`MessageDigest.isEqual`), not `Arrays.equals` or `==`, to avoid timing side-channels (the deeper why is in the password-storage foundations topic). ## Checked exceptions `getInstance` throws `NoSuchAlgorithmException`; `generateSecret` throws `InvalidKeySpecException`. Both are checked; handle or wrap them. ## Why not just SHA-256? Because it's fast and unsalted by default — exactly the wrong properties. PBKDF2 = salt + tunable slowness, both built into the spec.