Ignoring the salt would also work on older PHP versions. Though I think it's not expected behaviour to simply ignore the salt if it is passed. So I am 👎 on this change.

IMO, the behavior should be consistent: if the user pass a salt, we use it.

According to @ircmaxell:

"One thing has become abundantly clear to me: the salt option is
dangerous. I've yet to see a single usage of the salt option that has
been even decent. Every usage ranges from bad (passing mt_rand()
output) to dangerous (static strings) to insane (passing the password
as its own salt).

I've come to the conclusion that I don't think we should allow users
to specify the salt."

So I don't think it is a good idea to keep allowing users to pass a salt since the recommended way is to rely on the internal salt generation. And it might be promoting bad practices if we know it's not safe but still allow it

Well, we could think about deprecating the ability to pass a salt. At least, that would be less confusing and would step away from silently allow insecure usage of the encoder.

Indeed, doing the same as PHP password_hash function makes sense to me.

@pierredup Do you plan to finish this one in the near future?

@fabpot I'm not exactly sure what to do here.
Deprecating the option to pass a salt will have an effect on other encoders as well (like the Pbkdf2PasswordEncoder). In that case do we want to have our own salt generating function? Or how should the salt be handled for encoders that requires a salt (like pbkdf2) and others where it's not needed (like bcrypt)?

My suggestion would be to always generate the salt yourself. Never accept a passed in salt. There is no reason to accept a non-generated one, especially if you use standard algorithms.

This is a BC break though, so perhaps deprecate it first.

Replaced by #16459
Thank you @pierredup for raising the issue