What's the password storage format when using the DelegatingPasswordEncoder?

Question

Options

• AencodedPassword{id}, where {id} is an identifier used to look up which PasswordEncoder should
• B{id}encodedPassword, where {id} is an identifier used to look up which PasswordEncoder should
• C{timestamp}encodedPassword, where {timestamp} is the time when the password was encoded.
• D{id}{salt}encodedPassword, where {id} is an identifier used to look up which PasswordEncoder

• A
  4% (1)
• B
  92% (23)
• D
  4% (1)

Explanation

DelegatingPasswordEncoder stores passwords in the format {id}encodedPassword, where the {id} prefix (including curly braces) identifies which PasswordEncoder was used - for example, {bcrypt}$2a$10$... or {noop}plaintext. This design allows Spring Security to support multiple encoding algorithms simultaneously and migrate legacy passwords without breaking existing hashes.

Why the distractors are wrong:

• A reverses the order - the {id} must come first so the encoder can be identified before attempting to decode.
• C is fabricated - no timestamp is stored; timestamps would bloat storage and serve no decoding purpose.
• D is also fabricated - the salt is embedded inside the encoded password itself (handled by the algorithm), not as a separate prefix field.

Memory tip: Think of it as a label-first convention - you read the label {id} on the jar before opening it to know how to process the contents. The format mirrors how you'd tag a file: type first, then data.

No community discussion yet for this question.