(Is EmailAuth 2FA at all? I would argue not, because your password ceases to have any meaning as you can reset it with your email address, which makes your email address effectively the only factor)

In T394105#10818588, @Pppery wrote:

(Is EmailAuth 2FA at all? I would argue not, because your password ceases to have any meaning as you can reset it with your email address, which makes your email address effectively the only factor)

We've been considering it to be a weak form of 2fa if a user already had a confirmed email address that hadn't been recently changed.

In T394105#10818588, @Pppery wrote:

(Is EmailAuth 2FA at all? I would argue not, because your password ceases to have any meaning as you can reset it with your email address, which makes your email address effectively the only factor)

IMHO, it's still better than nothing, in case of stolen credentials.

Determining a list of eligible Wikimedia users. Everyone? Privileged users?

I would make it generally available, yes.

How to best support this in addition to other mechanisms such as OATH and WebAuthn.

For placement in the UI, perhaps under "Email options" as "Send a one-time code to my email address whenever I login to my account"? And maybe only enable that option after a user has verified their email address.

Who manages support for this feature, especially if it's rolled out to millions of Wikimedia accounts?

What type of support do you have in mind?

In T394105#10822934, @kostajh wrote:

I would make it generally available, yes.

We don't make proper 2FA generally available out of concerns of scaling up support for people who lock themselves out accidentally. Not sure if this would be very different in that regard.

For placement in the UI, perhaps under "Email options" as "Send a one-time code to my email address whenever I login to my account"?

Wouldn't it make more sense to integrate it in the 2FA management form?

And maybe only enable that option after a user has verified their email address.

What should happen if the email address becomes unverified again (because of BounceHandler or because the user is changing it)?
What should happen if the user is unsetting their email?

In T394105#10822340, @sbassett wrote:

We've been considering it to be a weak form of 2fa if a user already had a confirmed email address that hadn't been recently changed.

We don't actually check for recency currently, but maybe we should?

In T394105#10822993, @Tgr wrote:

In T394105#10822934, @kostajh wrote:

I would make it generally available, yes.

We don't make proper 2FA generally available out of concerns of scaling up support for people who lock themselves out accidentally. Not sure if this would be very different in that regard.

It's a lot easier for less technical users to lose thier TOTP codes. It would be harder to do that with email. My guess is that there would be fairly few support requests if this is generally available for users with verified email, who then don't have access to the email address anymore. We could also still make this opt-in enabling of EmailAuth follow LoginNotify's rules for recognizing a known IP or cookie for the account, which would allow users who are unable to access to their email to still login from a known device/ IP.

For placement in the UI, perhaps under "Email options" as "Send a one-time code to my email address whenever I login to my account"?

Wouldn't it make more sense to integrate it in the 2FA management form?

Maybe, not sure what is more easily discoverable.

And maybe only enable that option after a user has verified their email address.

What should happen if the email address becomes unverified again (because of BounceHandler or because the user is changing it)?
What should happen if the user is unsetting their email?

I suppose we would disable the EmailAuth opt-in for that user, and the user would have to opt-in again.

We should still requires users with CU/OS/editing site JS right (e.g. stewards, staffs) true 2FA which is not EmailAuth.