Spring Security's default approach is DelegatingPasswordEncoder. It encodes new passwords with the current recommended algorithm and tags each stored value with an id in braces, so it can still verify older formats. Before version 5.0 the default was a no op encoder that required plain text passwords.
What it solves
The Spring Security reference lists three real world problems: many applications use old encodings that cannot easily migrate, the best practice for password storage will change again, and a framework cannot make breaking changes often. DelegatingPasswordEncoder answers all three by encoding with current recommendations, validating modern and legacy formats, and allowing the encoding to be upgraded later.
The storage format
Each stored password starts with an id that tells Spring which encoder produced it:
{id}encodedPassword
The id must come first, start with an opening brace and end with a closing brace. If the id cannot be found, it is treated as null, and matching fails. The reference lists ids for several encoders, including bcrypt, pbkdf2, scrypt, argon2 and, for legacy compatibility, noop and sha256.
| Id | What it is |
|---|---|
| bcrypt | Adaptive hash, the encoder used for new passwords in the documented setup |
| pbkdf2, scrypt, argon2 | Other adaptive hashes |
| noop | Plain text, for tests only |
| sha256 | Legacy, kept for old data |
The docs name bcrypt, PBKDF2, scrypt and argon2 as examples of adaptive one way functions, which are deliberately resource intensive so guessing is slow.
Steps for your app
- Create the encoder with the factory the reference describes rather than hand building a map.
- Search your database for stored values without an id prefix. They need a migration plan.
- Search for noop and sha256 ids. Those are legacy and should be re-encoded when users next sign in.
- Check whether your code enables upgrade of encodings, so old hashes become current ones after a successful login.
- Never use the no op encoder outside tests.
- Do not tune the work factor down to speed up logins. The docs note that nothing in Spring Security can speed up password verification without losing security. Exchange the long term credential for a short term one such as a session or token.
Where scanners fit
A scanner will flag a vulnerable cryptography library, but it will not know your stored hashes are weak. Keep the library current and review how passwords are stored. See our Spring Boot security dependency guidance.
Safeguard scans dependencies, produces SBOMs and uses reachability analysis to show which findings your code can actually reach. You can run a free scan at gold.safeguard.sh/scan.
Quick check
Why does my hash start with a braced word?
That prefix is the id DelegatingPasswordEncoder uses to pick the matching encoder when it verifies a password.
Can I store plain text with noop?
The id exists, but it is for tests and legacy data. Use an adaptive hash for real accounts.
Sources
Last reviewed: 19 October 2026.
