Behavior change in `NoOpPasswordEncoder` with empty passwords

[StefanHenke]

Describe the bug

With Spring Security 6, it was possible to define users with an empty password (ie. length zero) that get successfully validated by NoOpPasswordEncoder which seems to be not the case in Spring Security 7 anymore. Primary reason seems to be within AbstractValidatingPasswordEncoder which turns the logic in matches method vice-versa and adds a length() check in addition to a null check. This change was not obvious for us to find. As it was not documented anywhere, we are wondering if this change in behavior was by intention.

As we use NoOpPasswordEncoder in our unit testing and local testing, it has a certain impact to adopt to this change.

To reproduce

Spring Boot 4.x, Spring Security 7.x

Expected behavior

First of all, we would like to clarify if this change was intentionally. And second if the original behavior from Spring Security 6 can be restored. Especially from the perspective that NoOpPasswordEncoder is not meant for productive use cases.

[rwinch]

The changes are intentional and done as a defensive measure as it seems unlikely that an empty String password should ever be considered a way of authenticating a user.

I'd like to learn a bit more about your use case around allowing an empty String password to be validated. Can you provide details as to why you would want this behavior?

[spring-projects-issues]

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

[spring-projects-issues]

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.