For some background on how this would be a problem, see #28093

For an alternative to auto, see:

https://docs.spring.io/spring-security/site/docs/5.1.5.RELEASE/reference/html5/#pe-dpe
https://docs.spring.io/spring-security/site/docs/5.1.5.RELEASE/api/org/springframework/security/crypto/password/DelegatingPasswordEncoder.html
https://docs.spring.io/spring-security/site/docs/5.1.5.RELEASE/api/org/springframework/security/crypto/factory/PasswordEncoderFactories.html#createDelegatingPasswordEncoder--

(from #31019 (comment))

How is this an alternative to auto? Spring recommends exactly the same as the new option to me.

@nicolas-grekas The difference with the DelegatingPasswordEncoder in Spring is that the app developer is in control of which algorithms are being used. The NativePasswordEncoder in Symfony does not provide that control.

See MigratingPasswordEncoder, which is the one that you should compare DelegatingPasswordEncoder to.

But which are the encoders we can use with MigratingPasswordEncoder, when they're all deprecated in favour of NativePasswordEncoder?

For example, I want to be able to use MigratingPasswordEncoder with argon2id as the "best" encoder, and argon2i and bcrypt as "extra" encoders. (Not a fictional but actual requirement.)

@nicolas-grekas MigratingPasswordEncoder is fine, but still does not give you control over the algorithm being used. It gives you control over the encoder being used, but our non-deprecated encoders are not about an algorithm, but about an implementation.

I also think that using something else that auto should not trigger a deprecation warning.
On an application dealing with legacy users, you want to force the algorithm used.
I don't see why Symfony should care about your data, to the point of raising deprecation warnings (well, at least not if you are using a hashing algorithm considered safe).

Implementation wise, this should be a new constructor argument to native/sodium encoders.
Anyone up for a PR?

I'm on it.