Illogical flow for PasswordSignInAsync through PreSignInCheck when RequireConfirmedEmail = true

[Ponant]

App Requirement: require confirmed email before user can login.
When you require a confirmed email in Startup.cs, checking whether the email is confirmed or not makes little sense until the POST username and pwd match what is in the DB.

The current flow for login violates this because PasswordSignInAsync calls PreSignInCheck prior to CheckPasswordAsync, an order which makes sense only for checking LockOut but not for email confirmation. PreSignInCheck will return SignInResult.NotAllowed for an unconfirmed email.

This flow makes it unnatural to fulfil the following likely scenario:
-User registers and an email is sent to him. He never receives this email or forgets to confirm it.
-He tries nevertheless to login, and enters the correct credentials .
-Since he entered the correct credentials, we can reveal to him that he should first confirm his email before we persist the cookie and we could propose him to resend a confirmation email. This flow will be safer than the one in the docs because the user entered the correct credentials (hence confirming his identity)

I tried to override PasswordSignInAsync but I hit SignInOrTwoFactorAsync, which is private.
The more natural way to avoid unnecessary code checks would be something around the following for
CheckPasswordSignInAsync

user IsLockedOut?
       Yes-->NotAllowed
       No-->Continue
UserName and Password Match?
       Yes -->EmailConfirmed?
                   -->Yes-->Success
                   -->No-->result="EmailNotConfirmedYet"
       No--> LockoutIncrement

PhoneNumber confirmation not mentioned. Unfortunatly the SignInResult may need to be extended to become more granular such that NotAllowed becomes split into

--UnconfirmedEmail
--UnconfirmedPhone

[HaoK]

We can look at this as part of https://github.com/aspnet/Identity/issues/1058 which currently scheduled for 2.1

[scottsauber]

Just +1'ing the flow mentioned here:

user IsLockedOut?
Yes-->NotAllowed
No-->Continue
UserName and Password Match?
Yes -->EmailConfirmed?
-->Yes-->Success
-->No-->result="EmailNotConfirmedYet"
No--> LockoutIncrement

I'm running up against this today where I don't want to expose that the Email is not confirmed unless the password they entered is valid.

[scottsauber]

Any update on where we are at with fixing this issue? This is a bit of an account enumeration risk with not checking the password first before checking if the Email is confirmed (or Phone # is confirmed if you have that turned on).

[HaoK]

In general we haven't been worrying about account enumeration I don't think, @blowdart thoughts?

[blowdart]

We don't care about account enumeration because there are lots of ways to do it - like trying to register a new user

[Ponant]

What we are talking about here is a flow which is superior to the current one while maintaining a liberty in configuration.

[blowdart]

As with the other issue, we're not going to split messaging or provide more details. The flow has hopefully changed for the better, but it's not changing like this.

If, with the new flow, you're still hitting issues, we'd take a PR to move something from private to protected if it makes it easier for you, and it's doesn't expose us to horribly breaking changes if we need to change it in the future.