Password Hashing

What is Password Hashing — and Why is it Not Encryption?

Hashing is a one-way function: given the output, there is no key, no algorithm, and no amount of computation that recovers the input directly — the only way "back" is to guess inputs and hash each guess until one matches. Encryption is two-way by design: whoever holds the key can decrypt and recover the original plaintext. Passwords must never be stored with encryption, however strong, because encryption's entire value proposition — reversibility — is the one property a stored credential must never have. If your database is ever exfiltrated, a hashed password forces the attacker into a computationally expensive guessing game; an encrypted password is fully recovered the instant the key is also found, which in practice means the moment the same breach also reaches your application server or secrets store.

The second half of the problem is which hash function. A cryptographic hash built for speed and integrity checking — MD5, SHA-1, SHA-256 — is the wrong tool here for the opposite reason it's the right tool elsewhere: it's fast. A modern GPU can compute billions of SHA-256 hashes per second, which turns "guess every password until one matches" from theoretical into a same-day attack against any password of realistic length. Password hashing needs a function that is deliberately, tunably slow.

// BEFORE — reversible encryption "just in case we need to recover it"
@Entity
public class Customer {
    private String encryptedPassword;   // AES-encrypted with a key stored in application config
}

public void register(String rawPassword) {
    String encrypted = aesCipher.encrypt(rawPassword, secretKey);
    customer.setEncryptedPassword(encrypted);
    // If the database AND the key are ever both exposed — the same breach that
    // reaches your app server config typically reaches both — every password
    // in the table is immediately, fully recovered in plaintext. No guessing
    // required, no work factor to slow the attacker down.
}

// AFTER — one-way, adaptive hash; the plaintext password never persists anywhere
@Entity
public class Customer {
    private String passwordHash;   // e.g. $2a$12$N9qo8uLOickgx2ZMRZoMy... (bcrypt, self-describing)
}

public void register(String rawPassword) {
    customer.setPasswordHash(passwordEncoder.encode(rawPassword));
    // A breach now hands the attacker a hash they must brute-force one guess
    // at a time, at a cost per guess that bcrypt/Argon2 make deliberately high.
}

Hashing vs Encryption vs Encoding — The Confusion Every Junior Has Once

These three terms get used interchangeably in casual conversation and describe entirely different, non-interchangeable operations. Confusing them is how "we base64-encoded the password before storing it" ends up in a production codebase — base64 is not security at all, it's a reversible text representation with zero secret involved.

Salt, Pepper, and Work Factor — The Three Levers

Salt — defeats precomputed lookup tables

/*
 * Without a salt, two users with the password "Password123!" produce the
 * identical hash. An attacker who precomputes a "rainbow table" — hashes for
 * billions of common passwords — cracks every matching row in the database
 * in one lookup, no per-password computation needed at attack time.
 *
 * A salt is random data generated per password and stored alongside the hash
 * (it is NOT secret — its only job is uniqueness). It's mixed into the input
 * before hashing, so identical passwords produce completely different hashes:
 *
 *   hash("Password123!" + salt_A) = "$2a$12$N9qo8uLOickgx2ZMRZoMy..."
 *   hash("Password123!" + salt_B) = "$2a$12$EixZaYVK1fsbw1ZfbX3OX..."
 *
 * This forces the attacker to attack each hash individually — a precomputed
 * table is useless because it would need one entry per possible salt value,
 * which defeats the entire point of precomputing.
 */

Work factor — the deliberate cost that scales with hardware

// BCryptPasswordEncoder's constructor argument is the "log rounds" cost factor:
// the algorithm runs 2^cost internal rounds. Each +1 DOUBLES the compute time.
@Bean
public PasswordEncoder passwordEncoder() {
    return new BCryptPasswordEncoder(12);   // 2^12 = 4096 rounds — ~250ms per hash on typical server hardware in 2026
}

/*
 * This 250ms is imperceptible for one login attempt, but devastating for an
 * offline brute-force attacker who must pay that cost for every single guess,
 * for every single password in a stolen database. At 4 hashes/second on
 * commodity hardware instead of billions/second with a fast hash, an 8-character
 * random password goes from "cracked in hours" to "impractical within any
 * reasonable timeframe or budget."
 *
 * Cost factor must be revised upward over time — hardware gets faster, and a
 * work factor tuned in 2020 provides less real protection every year it goes
 * untouched. Periodically re-benchmark for ~200-300ms per hash on current
 * production hardware, and bump the cost factor accordingly at deploy time.
 */

Argon2 — Why OWASP Recommends it Over bcrypt for New Systems

bcrypt has one dial: computational cost. Argon2 (the winner of the 2015 Password Hashing Competition) adds a second dimension — memory cost — which specifically defeats an attack class bcrypt doesn't: custom ASIC and GPU hardware that has cheap compute but limited fast memory per parallel unit. Forcing every guess to also allocate a configurable amount of RAM makes building cheap parallel-cracking hardware significantly harder. Use the Argon2id variant — it combines resistance to side-channel timing attacks with resistance to GPU cracking, which the plain Argon2i/Argon2d variants only cover individually.

@Bean
public PasswordEncoder passwordEncoder() {
    return new Argon2PasswordEncoder(
        16,     // salt length in bytes
        32,     // hash length in bytes
        1,      // parallelism
        1 << 16, // memory cost in KB — 65536 KB = 64 MB per hash computation
        3       // iterations
    );
}
// Spring Security's Argon2PasswordEncoder defaults to Argon2id under the hood.
// Tune memory cost to what your infrastructure can actually afford per login —
// 64MB per concurrent hash computation adds up fast under login-endpoint load,
// which is exactly the trade-off that makes it expensive for an attacker too.

Spring Security in Practice — Encoding, Verifying, and Migrating Algorithms

// DTOs as records
public record RegistrationRequest(String email, String rawPassword) {}

@Service
public class CustomerRegistrationService {

    private final CustomerRepository customerRepository;
    private final PasswordEncoder passwordEncoder;

    // Constructor injection — single constructor, no @Autowired needed (Spring 4.3+)
    public CustomerRegistrationService(CustomerRepository customerRepository, PasswordEncoder passwordEncoder) {
        this.customerRepository = customerRepository;
        this.passwordEncoder = passwordEncoder;
    }

    public Customer register(RegistrationRequest request) {
        Customer customer = new Customer();
        customer.setEmail(request.email());
        customer.setPasswordHash(passwordEncoder.encode(request.rawPassword()));
        // The raw password is never persisted, logged, or held longer than this call.
        return customerRepository.save(customer);
    }
}

// Verifying a login — never compare hashes with String.equals()
public boolean checkPassword(String rawPassword, String storedHash) {
    return passwordEncoder.matches(rawPassword, storedHash);
    // matches() re-derives the salt from the stored hash string itself (bcrypt and
    // Argon2 both embed it) and performs a constant-time comparison internally —
    // handling this yourself with == or .equals() on the raw bytes reintroduces
    // a timing side-channel that leaks how many leading bytes matched.
}

Migrating hash algorithms without forcing a password reset

// DelegatingPasswordEncoder reads a {id} prefix from the stored hash to know
// which algorithm verified it — this is what PasswordEncoderFactories provides
// by default, and it's the mechanism that makes algorithm migration painless.
@Bean
public PasswordEncoder passwordEncoder() {
    return PasswordEncoderFactories.createDelegatingPasswordEncoder();
    // New hashes are encoded with the current default (bcrypt as of this writing),
    // stored as "{bcrypt}$2a$10$...". A legacy row stored as "{noop}rawpassword"
    // or "{sha256}abc123..." from a previous system still verifies correctly —
    // the prefix tells DelegatingPasswordEncoder which encoder to delegate to.
}

// Upgrade-on-login pattern: transparently re-hash with the current algorithm
// the next time a user with a legacy hash successfully authenticates
@Service
public class LoginService {

    private final CustomerRepository customerRepository;
    private final PasswordEncoder passwordEncoder;

    public LoginService(CustomerRepository customerRepository, PasswordEncoder passwordEncoder) {
        this.customerRepository = customerRepository;
        this.passwordEncoder = passwordEncoder;
    }

    public void login(String email, String rawPassword) {
        Customer customer = customerRepository.findByEmail(email)
            .orElseThrow(() -> new BadCredentialsException("Invalid credentials"));

        if (!passwordEncoder.matches(rawPassword, customer.getPasswordHash())) {
            throw new BadCredentialsException("Invalid credentials");
        }

        // upgradeEncoding() is exposed via PasswordEncoder's UserDetailsPasswordService
        // integration in Spring Security — conceptually: if the stored hash uses
        // an outdated prefix, re-encode with the current default and persist it,
        // now that we have the raw password in hand for this one request only.
        if (passwordEncoder instanceof DelegatingPasswordEncoder delegating
                && delegating.upgradeEncoding(customer.getPasswordHash())) {
            customer.setPasswordHash(passwordEncoder.encode(rawPassword));
            customerRepository.save(customer);
        }
    }
}

Modern Password Policy — What NIST 800-63B Actually Changed

Older password policy guidance — mandatory special characters, forced rotation every 90 days — is now considered counterproductive by NIST's own current digital identity guidelines. Forced rotation trains users toward predictable, incrementing passwords (Summer2024! → Summer2025!); character-class requirements push people toward writing passwords down or reusing a single "compliant" password everywhere. Length, not complexity, is the strongest lever a policy actually controls.

// A defensible modern policy for a customer-facing e-commerce account:
//
// - Minimum 12 characters, no arbitrary maximum below 64
// - No mandatory character-class composition rules
// - No forced periodic rotation (rotate only on suspected compromise)
// - Check against a known-breach corpus at registration/change time
// - Rate-limit login attempts; lock or delay after repeated failures

// Checking a password against known breaches via the HaveIBeenPwned k-anonymity
// API — only the first 5 characters of the SHA-1 hash are sent, never the
// password itself, so the third party never sees anything identifying
@Service
public class BreachedPasswordChecker {

    private final RestClient restClient;

    public BreachedPasswordChecker(RestClient.Builder builder) {
        this.restClient = builder.baseUrl("https://api.pwnedpasswords.com").build();
    }

    public boolean isBreached(String rawPassword) {
        String sha1 = DigestUtils.sha1Hex(rawPassword).toUpperCase();
        String prefix = sha1.substring(0, 5);
        String suffix = sha1.substring(5);

        String response = restClient.get().uri("/range/{prefix}", prefix)
            .retrieve().body(String.class);

        return response.lines()
            .anyMatch(line -> line.startsWith(suffix));
        // Reject at registration, don't silently allow — a password already in a
        // public breach corpus is compromised before the account even exists.
    }
}

Best Practices and Common Pitfalls

Interview Questions