Optionally Force 2fa

[mikeselander]

Fixes #255.

Adds a network-level and site level (if non-multisite) setting to require two-factor authentication on a per-role or global level. If 2fa forcing is on and a user matches the criteria, we force the user into a 2fa settings screen and they cannot use the site until they add valid 2fa to their account.

Super administrators can edit the settings with this interface via network (or site if single site) settings:

Users who fall within the required buckets will see an interface like this:

[mikeselander]

Hey folks, apologies - this is nowhere near review ready and I hit the wrong button 🤦‍♂️

[kasparsd]

@mikeselander This looks great! Will you open a new pull request later or should I re-open this one?

[mikeselander]

@kasparsd it still needs quite a bit of smoothing out which I'll be working on today. I'll re-open this once it's in a better state :)

[alexclst]

I look forward to when this gets included. Any updates on the state of this?

[jeffpaul]

@alexclst this is still in need of someone picking up the existing work in the PR and updating based on feedback in #239 (review).

[iandunn]

I agree with Kaspars that this would be much simpler if we just redirected to the profile page instead of setting up an interstitial UI. I also agree with Mike, though, about the poor UX of that page.

I think the best way forward would be to:

1. Remove all the extra code in this PR, so that it just removes capabilities and does the redirect. That would make this simple and lean.
2. Open a new issue to improve the UI/UX, including maybe moving it to its own page. That would improve it for all flows, instead of just the one where 2FA is being enforced.

[rmccue]

There's a fairly significant disadvantage to using the profile page, which is that it requires rendering the entire admin. This potentially increases the attack surface and could lead to undesirable behaviour for plugins that aren't aware of the 2FA plugin. Keeping it siloed either on the frontend or login ensures nothing from the admin is accidentally leaked that way.

[iandunn]

🤔 Wouldn't removing the user's capabilities solve that (assuming the plugin is written correctly)? Or are you thinking of something different?

[joehoyle]

I've fixed the merge conflicts here!

[joshbetz]

Maybe this is obvious, but removing caps only serves to motivate people to enable Two Factor. It doesn't enhance security because anyone with the username and password can just enable 2FA to get full access. If you have a privileged user that never enables 2FA (maybe they don't login for a long time), their account is still vulnerable via a pwned password.

I would suggest an alternative way to think about this might be to enable Email by default for anyone that doesn't have other factors and then require everyone to have at least 1 factor enabled. (So you could disable email after enable TOTP, for example.)

I know this gets complicated if you want to enable Email as a factor, so maybe the default factor could be configurable. For example, maybe you want an admin to be able to generate a backup code and deliver it out of band.

[joshbetz]

Could be as simple as:

	add_filter( 'two_factor_enabled_providers_for_user', 'force_2fa', 10, 2 );
	function force_2fa( $enabled, $user_id ) {
		if ( ! $force_2fa ) {
			return $enabled;
		}
		
		if ( count( $enabled ) ) {
			return $enabled;
		}

		return [ 'Two_Factor_Email' ];
	}

[NewJenk]

Could be as simple as:

	add_filter( 'two_factor_enabled_providers_for_user', 'force_2fa', 10, 2 );
	function force_2fa( $enabled, $user_id ) {
		if ( ! $force_2fa ) {
			return $enabled;
		}
		
		if ( count( $enabled ) ) {
			return $enabled;
		}

		return [ 'Two_Factor_Email' ];
	}

I think there's a minor typo here, guessing $force_2fa should be $user_id, like this:

add_filter( 'two_factor_enabled_providers_for_user', 'force_2fa', 10, 2 );
function force_2fa( $enabled, $user_id ) {
	if ( ! $user_id ) {
		return $enabled;
	}

	if ( count( $enabled ) ) {
		return $enabled;
	}

	return [ 'Two_Factor_Email' ];
}

I've quickly tested this locally and it seems to work great - a really nice way to quickly and conveniently enforce email 2fa. It also automatically pre-selects email on the user settings screen, so if a user wants to change 2fa settings they'll see that email is pre-selected.

[alexclst]

There should be a way to hard-code the force settings from wp-config.php, so that we can enforce these in a way that normal admin users cannot change. While filters are more capable, I think that also having a define we can add would further harden security. Otherwise one admin could get 2FA set up, and then disable the requirement right away.

[jeffpaul]

@iandunn @joehoyle @georgestephanis is there a preferred approach to either getting this updated and towards merge (or perhaps closed with a fresh PR and new approach and then towards merge)? If so, I can try and help pull some engineering time to get this to done.