Password Encoding with PasswordEncoder

#Introduction

PasswordEncoder is the Spring Security interface used to hash passwords before storing them in the database and to verify passwords during login. Hashing is one-way: unlike encryption, the original password can't be recovered from the stored value.

#Why Do We Need It?

Bad practice — storing the plain password:

password = "admin123";

admin123

If the database is ever leaked or breached, every user's password is exposed — and since people reuse passwords, their email and bank accounts are at risk too.

Good practice — storing a hash:

passwordEncoder.encode("admin123");

$2a$10$XJfL4P3fX8j...

The original password can't be recovered from the hash.

#Configure a PasswordEncoder Bean

@Bean
public PasswordEncoder passwordEncoder() {
    return new BCryptPasswordEncoder();
}

BCryptPasswordEncoder is the most commonly used encoder in Spring Security.

@Bean
public PasswordEncoder passwordEncoder() {
    return PasswordEncoderFactories.createDelegatingPasswordEncoder();
}

#During Registration

The user enters admin123:

String encodedPassword = passwordEncoder.encode("admin123");
user.setPassword(encodedPassword);
repository.save(user);

$2a$10$8oQ0b1N8n7wq6v...

#During Login

The user enters admin123; the database contains $2a$10$8oQ0b1N8n7wq6v.... Spring Security calls:

passwordEncoder.matches("admin123", storedHash);   // true

#Why Is the Hash Different Every Time?

System.out.println(passwordEncoder.encode("admin123"));
System.out.println(passwordEncoder.encode("admin123"));

$2a$10$abc...
$2a$10$xyz...

Both are different because of a random salt. Yet both of these return true:

passwordEncoder.matches("admin123", hash1);   // true
passwordEncoder.matches("admin123", hash2);   // true

#How Login Works Internally

If matches() returns true, authentication succeeds; otherwise a BadCredentialsException is thrown and the user gets a "bad credentials" response.

#Password Encoding with Salt

A salt is a random value added to a password before hashing.

Without Salt

Password: admin123
SHA-256(admin123) = 240be518...

Every user with the password admin123 gets the same hash:

This makes rainbow-table attacks possible (huge precomputed tables of password → hash), and an attacker can see at a glance which users share a password.

With Salt

User 1:  salt = X7K9P2   Hash(admin123 + X7K9P2) = A1B2C3D4...
User 2:  salt = M5N8Q1   Hash(admin123 + M5N8Q1) = Z9Y8X7W6...

Same password, different hashes — precomputed tables become useless.

How BCrypt Uses Salt

When you call encoder.encode("admin123"), BCrypt automatically:

1. generates a random salt;
2. combines the password and salt;
3. applies the BCrypt hashing function many times (the work factor);
4. stores the salt inside the final hash string.

$2a$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy

The salt is embedded in the hash itself — no separate database column is needed.

The Verification Process

1. Extract the salt (and cost) from the stored hash.
2. Hash the entered password using the same salt and cost.
3. Compare the generated hash with the stored hash.
4. Return true or false.

#Common Password Encoders

Never use NoOpPasswordEncoder (plain text), or fast general-purpose hashes like MD5, SHA-1 or a single SHA-256 for passwords.

#Example

@Autowired
private PasswordEncoder passwordEncoder;

String hash = passwordEncoder.encode("admin123");
boolean valid = passwordEncoder.matches("admin123", hash);
System.out.println(valid);   // true

This is exactly what Spring Security does behind the scenes when the AuthenticationManager authenticates a username and password.

#Key Takeaways

• PasswordEncoder hashes passwords on registration and verifies them on login.
• Hashing is one-way — the original password can't be recovered.
• A random salt makes identical passwords produce different hashes; BCrypt stores it inside the hash.
• Always verify with matches(), never equals().
• Login flows through AuthenticationManager → DaoAuthenticationProvider → UserDetailsService → PasswordEncoder.matches().