Password Hashing in Java: BCrypt vs Argon2 vs PBKDF2 with Spring Security 7

Versions tested. Spring Security spring-security-crypto 7.1.1 (GA; the Spring Boot 4.1.1 line, GA September 2026), spring-core 7.0.9, BouncyCastle bcprov-jdk18on 1.86 (needed by Argon2), JDK 25.0.4.1 LTS (Temurin). Versions were read from maven-metadata.xml on Maven Central on 17 October 2026. Timings were taken on a 2-vCPU cloud sandbox, so your milliseconds will differ — the ratios and the behaviours are what carry over.

One thing that cost a run while writing this: spring-security-crypto 7.1.1 declares spring-core as optional, but matches() calls org.springframework.util.StringUtils. Using the crypto module on its own, without Spring Boot, ends in NoClassDefFoundError on the first matches() call until you add spring-core yourself.

A good hash is slow on purpose

• PBKDF2 burns CPU time only (a loop of HMACs). Cheap to run on GPUs, so it needs a very high iteration count. It is the one NIST has long approved.
• BCrypt burns CPU with a small, awkward memory pattern (4 KB) that was hard for GPUs in 1999 and is still annoying. The cost factor is a power of two.
• scrypt and Argon2id are memory-hard: each guess needs megabytes of RAM, which is what limits an attacker running thousands of guesses in parallel. Argon2id won the 2015 Password Hashing Competition.

static void time(String label, PasswordEncoder enc) {
    String pw = "correct horse battery staple";
    enc.encode(pw); // warm-up so JIT does not distort the first number
    int runs = 5;
    long total = 0;
    String last = null;
    for (int i = 0; i < runs; i++) {
        long t0 = System.nanoTime();
        last = enc.encode(pw);
        total += System.nanoTime() - t0;
    }
    System.out.printf("%-34s %7.1f ms   hash length=%d%n", label, total / runs / 1e6, last.length());
}

BCrypt cost=10                        77.2 ms   hash length=60
BCrypt cost=11                       148.6 ms   hash length=60
BCrypt cost=12                       301.3 ms   hash length=60
BCrypt cost=13                       606.6 ms   hash length=60
BCrypt cost=14                      1234.6 ms   hash length=60
PBKDF2-HMAC-SHA256 310k iter         436.1 ms   hash length=96
PBKDF2-HMAC-SHA256 600k iter         673.6 ms   hash length=96
Argon2id m=16MiB t=2 p=1              58.1 ms   hash length=97
Argon2id m=19MiB t=2 p=1 (OWASP)      70.8 ms   hash length=97
Argon2id m=64MiB t=3 p=1             532.1 ms   hash length=97
SCrypt N=2^15 r=8 p=1                186.7 ms   hash length=76

Do not copy parameters, copy the method. Look at the Argon2 rows. The commonly quoted OWASP-style setting (19 MiB, 2 iterations) took 71 ms here, far below a BCrypt cost-12 login, while 64 MiB with 3 iterations took 532 ms. The recommended minimums are floors for safety at a given memory size, not latency targets. Measure on the hardware that will serve logins, pick a latency budget you can afford under peak load (a few hundred milliseconds is typical), then raise the memory and iteration count until you reach it. Remember that every concurrent login holds that much memory: 64 MiB × 50 simultaneous logins is 3.2 GB.

<dependency>
  <groupId>org.springframework.security</groupId>
  <artifactId>spring-security-crypto</artifactId>
  <version>7.1.1</version>
</dependency>
<dependency>
  <groupId>org.bouncycastle</groupId>
  <artifactId>bcprov-jdk18on</artifactId>
  <version>1.86</version>
</dependency>
<dependency>
  <groupId>org.springframework</groupId>
  <artifactId>spring-core</artifactId>
  <version>7.0.9</version>
</dependency>
<dependency>
  <groupId>commons-logging</groupId>
  <artifactId>commons-logging</artifactId>
  <version>1.3.5</version>
</dependency>

DelegatingPasswordEncoder stores the algorithm in the hash

static DelegatingPasswordEncoder encoder() {
    Map<String, PasswordEncoder> encoders = new HashMap<>();
    encoders.put("bcrypt", new BCryptPasswordEncoder(10));
    encoders.put("pbkdf2@SpringSecurity_v5_8", Pbkdf2PasswordEncoder.defaultsForSpringSecurity_v5_8());
    encoders.put("argon2@SpringSecurity_v5_8", Argon2PasswordEncoder.defaultsForSpringSecurity_v5_8());
    // new hashes use argon2; old ones still verify via their own prefix
    return new DelegatingPasswordEncoder("argon2@SpringSecurity_v5_8", encoders);
}

The missing-prefix error. A hash with no {id} in front is rejected outright. From the same file’s output: IllegalArgumentException: Given that there is no default password encoder configured, each password must have a password encoding prefix. Please either prefix this password with '{noop}' or set a default password encoder in `DelegatingPasswordEncoder`. That is the fingerprint of importing a legacy table of raw BCrypt strings: either prefix them with {bcrypt} in a migration, or call setDefaultPasswordEncoderForMatches(...) as a stop-gap.

Upgrade the hash on login

static boolean login(DelegatingPasswordEncoder enc, String user, String password) {
    String stored = db.get(user);
    if (!enc.matches(password, stored)) {
        return false;
    }
    if (enc.upgradeEncoding(stored)) {              // stored hash uses an old algorithm / cost
        db.put(user, enc.encode(password));          // re-hash now: we hold the plaintext only here
        System.out.println("  -> upgraded stored hash for " + user);
    }
    return true;
}

before login : {bcrypt}$2a$10$cBuXoPOlx6MejxmlKGKM2uKue...
wrong password -> false
  -> upgraded stored hash for alice
good password  -> true
after login  : {argon2@SpringSecurity_v5_8}$argon2id$v=...
second login   -> true (no upgrade message expected)

The 72-byte trap

String base = "A".repeat(72);
String hash = enc.encode(base);
System.out.println("72-byte password hashes fine: " + enc.matches(base, hash));

String longer = base + "-and-anything-else-the-attacker-guesses";
try {
    String h2 = enc.encode(longer);
    System.out.println("encode(>72 bytes) accepted; matches(72-byte prefix)=" + enc.matches(base, h2));
} catch (IllegalArgumentException e) {
    System.out.println("encode(>72 bytes) rejected: " + e.getMessage());
}
try {
    System.out.println("matches(>72 bytes against 72-byte hash)=" + enc.matches(longer, hash));
} catch (IllegalArgumentException e) {
    System.out.println("matches(>72 bytes) rejected: " + e.getMessage());
}

72-byte password hashes fine: true
encode(>72 bytes) rejected: password cannot be more than 72 bytes
matches(>72 bytes against 72-byte hash)=true
emoji password: chars=38 utf8-bytes=76
emoji password rejected: password cannot be more than 72 bytes

What this means for your login form. If users may choose long passphrases (password managers love generating them), a plain BCrypt setup will either reject them at sign-up or, for legacy hashes, compare only their first 72 bytes. The fix is not to cap the user at 72 and hope: pre-hash the password to a fixed short string first, which is exactly what the next section does.

A pepper: a secret the database does not contain

private String prehash(CharSequence raw) {
    try {
        Mac mac = Mac.getInstance("HmacSHA256");
        mac.init(new SecretKeySpec(pepper, "HmacSHA256"));
        byte[] out = mac.doFinal(raw.toString().getBytes(StandardCharsets.UTF_8));
        return Base64.getEncoder().encodeToString(out);
    } catch (Exception e) {
        throw new IllegalStateException(e);
    }
}

@Override public String encode(CharSequence raw) { return delegate.encode(prehash(raw)); }
@Override public boolean matches(CharSequence raw, String stored) { return delegate.matches(prehash(raw), stored); }

100-char password with pepper: matches=true
same password, first 72 chars only: matches=false  (truncation gone)
stolen DB + wrong pepper: matches=false

The price of a pepper. You cannot rotate it casually: changing the pepper invalidates every stored hash, because the prehash output changes. A rotation scheme needs a version marker stored with each hash (for example a {pepper2} prefix handled by a delegating encoder) and the same upgrade-on-login migration as above. The demo here hard-codes the pepper in the source purely so the program is runnable — real peppers never live in code.

Which one should you pick?

Should you store passwords at all? Every algorithm above defends a database you hopefully never lose. If you can avoid passwords — passkeys, or delegating to an identity provider — do that instead. The post on passkeys and WebAuthn in Spring Security 7 shows the replacement, and JWT authentication in Spring Security 7.1 covers what happens after the password check succeeds.

Downloads

• HashTimings.java — timings for BCrypt, PBKDF2, Argon2id, scrypt
• DelegatingUpgrade.java — id prefixes and upgrade on login
• Bcrypt72ByteTrap.java — the 72-byte asymmetry
• PepperedEncoder.java — HMAC pepper wrapper

Further reading

• Spring Security reference: password storage
• OWASP Password Storage Cheat Sheet
• Hashing passwords in Python with bcrypt (same algorithm, other language)
• The Spring Security filter chain explained