Enforce 2FA for privileged accounts

[iandunn]

Core/Meta committers, super-admins, project leaders, committers to plugins w/ > 50k active installs, etc should be required to use 2FA of some kind. How strict we are should depend on what kind of access they have.

• [x] Require for super admins
• [x] Require for WordCamp super deputies
• [x] Require for WordCamp subroles
• [x] Disable on production for beta testing
• [ ] Enable on production once launches for all users
• [ ] (optional) Reorganize capes.php to make it easier to work with
• [ ] Determine which other roles should require it
• [ ] Require it for those roles
• [ ] Explore the idea of encouraging (but not requiring) it for some roles - probably open a separate ticket for that

Related:

• 4

• https://github.com/WordPress/two-factor/issues/255
• https://github.com/WordPress/two-factor/pull/239
• https://github.com/WordPress/two-factor/issues/249

[iandunn]

Related: wpcom_vip_two_factor_filter_caps() from https://github.com/Automattic/vip-go-mu-plugins/blob/develop/two-factor.php

[iandunn]

Rough idea:

• Default is opt-in
• Encouraged if
  • Make team representative
  • Admin on any w.org/wordcamp.org site
• Mandatory with TOTP or hardware key+webauthn if:
  • has write access to a github.com/wordpress repo
  • plugin has more than X installs
  • theme has more than Y installs
  • wordcamp trusted deputy
• Mandatory using hardware key + webauthn if:
  • has write access to (core|build|meta|dotorg|wordcamp|code).svn.w.org
  • w.org super admin
  • admin access to any github.com/wordpess repo
  • any other form of leadership – josepha, matt, chloe, matias, etc

Requiring a hardware key for the highest privilege group would prevent phishing. Most folks will never buy one though, so it’s important to not push it too hard. Maybe we give frequent contributors a coupon code so they can buy one on mercantile.w.org for the cost of shipping, or half price or something.

[iandunn]

To facilitate this, we may want to reorganize capes.php, so it has a group of functions like get_core_committers(), get_meta_committers(), get_wordcamp_deputies(), etc. They'd return an array of usernames, and could be used for the existing watch/supes logic. They could also be used by this plugin to define who needs to have 2FA enabled.

[iandunn]

The upstream PR needs a good amount of work IMO, so in this case it might be better if we build those parts here for the MVP, and contribute them upstream later. So this would do 3 things:

1. Check if the logged in user needs to enable 2FA
2. Remove their capabilities. This is necessary even though we'll redirect them, because otherwise they could still perform privileged actions on the front end, via the REST API, etc
3. Redirect them to the (front-end) page where they can enable it. The URL of that is still TBD, so we could just use the wp-admin profile for now, and update it once it exists.

[tellyworth]

Some of this belongs in later iterations IMO. Some of the underlying code probably needs to be in place (eg to avoid bypassing 2FA for accounts that have already enabled it), but 100% opt-in should be fine for the initial MVP release.

[iandunn]

👍🏻 I disabled the 2FA requirement in production environments in d00ba1b, and moved this issue to the Iteration 1 milestone.

Some of the underlying code probably needs to be in place (eg to avoid bypassing 2FA for accounts that have already enabled it)

d00ba1b made 2FA opt-in, but shouldn't prevent anyone from setting it up, or using it once it's enabled.