I'm all in favour of those restrictions, but how should a user a user proceed if they need to temporarily disable 2FA before setting it up on a new devise?

In T414952#11534370, @Johannnes89 wrote:

I'm all in favour of those restrictions, but how should a user a user proceed if they need to temporarily disable 2FA before setting it up on a new devise?

Given that now it is possible to set up many 2FA methods, the proposed way to go is to first set up 2FA on the new device and then remove the old one, so that for the whole time the user has at least one 2FA method.

Does it answer your concerns?

In T414952#11534765, @mszwarc wrote:

In T414952#11534370, @Johannnes89 wrote:

I'm all in favour of those restrictions, but how should a user a user proceed if they need to temporarily disable 2FA before setting it up on a new devise?

Given that now it is possible to set up many 2FA methods, the proposed way to go is to first set up 2FA on the new device and then remove the old one, so that for the whole time the user has at least one 2FA method.

I'm not sure that's feasible in all situations, but I suppose a user could just ask for temporary removal of their permissions if a scenario occurs where they need to temporarily deactivate 2FA.

Why should this prevented? What is the idea behind it?

MediaWiki can handle the situation without 2FA enabled. For example the user account get new rights that require 2FA, the account can still edit, but not use the extra rights. So in general it is possible to hold rights that are not usable ("Disabled group").

When 2FA is compromised or lost it must be possible to disable or remove that 2FA from the account. Asking for removal of user rights may take to long.
There is no need to block the removal of the last 2FA, maybe add an extra warning that the user group get disabled or is no longer usable.

In T414952#11535053, @Umherirrender wrote:

Why should this prevented? What is the idea behind it?

MediaWiki can handle the situation without 2FA enabled. For example the user account get new rights that require 2FA, the account can still edit, but not use the extra rights. So in general it is possible to hold rights that are not usable ("Disabled group").

When 2FA is compromised or lost it must be possible to disable or remove that 2FA from the account. Asking for removal of user rights may take to long.
There is no need to block the removal of the last 2FA, maybe add an extra warning that the user group get disabled or is no longer usable.

The general idea is to prevent users from only turning on 2FA when they want to use their interface admin permissions (or other rights which require 2FA). If 2FA "enforcement" just means disabling rights as long as 2FA is deactivated, malicious users could compromise a privileged account and then set up 2FA themselves...

Thanks @Johannnes89 – this is exactly the reason why we'd like to prevent some users from disabling their 2FA.

In T414952#11535053, @Umherirrender wrote:

When 2FA is compromised or lost it must be possible to disable or remove that 2FA from the account. Asking for removal of user rights may take to long.
There is no need to block the removal of the last 2FA, maybe add an extra warning that the user group get disabled or is no longer usable.

I believe our recommendation for that is to have at least two 2FA options configured, in which case any single of them will still be disable-able.

If there's something we could improve around the 2FA support, so that the need/chance for disabling 2FA becomes lower, let us know.

Some apps cannot gracefully transfer 2FA a priori. (I use one.) I'd have to set it up entirely from the start again, if it even allows me to, when I move devices.

T414907: Enforce 2FA-requiring groups using $wgRestrictedGroups is also a bad idea for the same reason.

In T414952#11592382, @Izno wrote:

Some apps cannot gracefully transfer 2FA a priori. (I use one.) I'd have to set it up entirely from the start again, if it even allows me to, when I move devices.

T414907: Enforce 2FA-requiring groups using $wgRestrictedGroups is also a bad idea for the same reason.

What do you mean by gracefully transfer a priori? Something similar in function to Google Authenticator's cloud sync?

Would a following scenario work for you?

• Once you get a new device, you set up 2FA up there from scratch (as a new 2FA method).
• At this point you've got two "second factors" – the old device and the new one.
• Then, you remove the old device from your account.

Change #1240622 had a related patch set uploaded (by Mszwarc; author: Mszwarc):

[mediawiki/extensions/OATHAuth@master] OATHManage: Prevent from disabling 2FA if it's required

https://gerrit.wikimedia.org/r/1240622

Change #1240623 had a related patch set uploaded (by Mszwarc; author: Mszwarc):

[mediawiki/extensions/OATHAuth@master] Display which groups require 2FA on Special:OATHManage

https://gerrit.wikimedia.org/r/1240623

Change #1240622 merged by jenkins-bot:

[mediawiki/extensions/OATHAuth@master] OATHManage: Prevent from disabling 2FA if it's required

https://gerrit.wikimedia.org/r/1240622

Change #1240623 merged by jenkins-bot:

[mediawiki/extensions/OATHAuth@master] Display which groups require 2FA on Special:OATHManage

https://gerrit.wikimedia.org/r/1240623

I have tested this on a local wiki farm setup. I cannot remove my last 2FA (either TOTP or Security key) when I am in at least one 2FA restricted group on one of the connected wikis.

Example for a user in one 2FA group on one wiki and two 2FA groups on another:

Change #1260028 had a related patch set uploaded (by Reedy; author: Reedy):

[mediawiki/extensions/OATHAuth@master] en.json: Fix two authentication typos

https://gerrit.wikimedia.org/r/1260028

Change #1260028 merged by jenkins-bot:

[mediawiki/extensions/OATHAuth@master] en.json: Fix two authentication typos

https://gerrit.wikimedia.org/r/1260028