Hey, thanks for your report!
There has not been a lot of activity here for a while. Is this bug still relevant? Have you managed to find a workaround?

Yes this is still relevant.

This is still relevant. The only workaround seems to be disabling the hide_user_not_found security setting and then checking the last authentication exception in the login controller and replacing a UserNotFoundException with a BadCredentials exception. This does seem to be brittle and better handled in the framework logic.

security.yaml:

security:
    hide_user_not_found: false

SecurityController.php:

		$authEx = $authUtils->getLastAuthenticationError(true);
		if ($authEx !== null) {
			// TODO due to what seems to be a bug in AuthenticatorManager#handleAuthenticationFailure:271
			// see https://github.com/symfony/symfony/issues/42793
			if ($authEx instanceof UserNotFoundException) {
				$authEx = new BadCredentialsException('Bad credentials.', 0, $authEx);
			}
		}
		return $authEx;

Hey, thanks for your report!
There has not been a lot of activity here for a while. Is this bug still relevant? Have you managed to find a workaround?

Hello? This issue is about to be closed if nobody replies.

Can confirm the issue. This looks like a bug, because the hideUserNotFoundExceptions toggle does not only hide "user not found exception" but also other technical errors like account is blocked

Quoting #56830 (comment):

The fact that whether built-in AccountStatusException are caught or not depends on the hide_user_not_found flag although they are not UserNotFoundException might sound weird, yet it is on purpose.
We did this as part of a security fix 3 years ago. Reasoning was that the use case such exceptions serve is pretty much the same as UserNotFoundException ones regarding user enumeration.

So if we want to change this, that would definitely be a new feature.
Also it should not be about suddenly stopping to catch those, first because that would be too much of a BC break and also because it would go against the decision that led to the CVE mentioned above. What could be done is to rename the flag for the sake of clarity or split it in two. Given the traction on related issues, I would be fine doing so.

Thanks for posting here on this bug fix.

Quoting #56830 (comment)

I'm not clear; is this fix now to revert the changes to only mask UserNotFoundException's?

Personally, I'm fine with that because I do not see much benefit to masking locked accounts. The account would be locked and there would normally be nothing a legitimate or malicious user could do to unlock the account. Only to accommodate others on this, it may be worth considering having two settings, eg. hideUserNotFoundExceptions and hideAllAuthExceptions.

In my project I see there are at least 3 places where this logic is implemented:

* security-http: Symfony\Component\Security\Http\Authentication\AuthenticatorManager: handleAuthenticationFailure

* security-core: Symfony\Component\Security\Core\Authentication\Provider\UserAuthenticationProvider: authenticate

* security-guard: Symfony\Component\Security\Guard\Firewall\GuardAuthenticationListener: executeGuardAuthenticator

Will these also be updated or are these others being phased out? Also, I assume this will be patched in 5.4+ going forward.