Account recovery after losing 2fa key

[Clorith]

Is your enhancement related to a problem? Please describe.

One of WordPress' strengths is its userfriendliness, but how do we combine that with account recoveries? Users will lose their 2fa generator (new phone for example), and non-technical users will lose backup codes. How can we ensure that users do not lose access to their site in this scenario (without over-burdening hosts needing to manipulate databases on their behalf)?

This was one of the major issues when 2fa was initially discussed for core, many many years ago, but I'd like to discuss, and find a good path forward for this.

Proposed Solution

A few solutions were proposed at the time, the most direct was to introduce a constant which the user could add to wp-config.php to temporarily disable 2fa altogether. I'm personally not a fan of this approach, as asking non-technical users to modify one of the most important files in a WordPress setup could have large ramifications.

My current though process is to borrow an idea I've seen used in games, where account takeovers were a major issue, but with a twist. Their setup is to lock account valuables with a bank pin (a static numeric code), and let you recover it by saying you forgot your pin, and then you have a week to wait, and if you do not sign in and cancel it in a week, it is just removed.

I don't think that's entirely sufficient, or time efficient enough, so I have an initial proposals to get the ball rolling, it has two possible paths; they're quite similar up to a point, then diverge, and come back together in the end:

• User signs in (this verifies they have a valid username and password)
• User is asked to provide 2fa details, which they do not have
• User clicks "I've lost my 2fa key" button on this screen

This is where the diverge happens, there are two approaches that make the most sense that I've thought over a bit for now;

Least resistance
An email (rate limited to one every 12 or 24 hours) is sent to the accounts email address, letting the user know that their 2fa token will be unset in $time hours, with a link to cancel the request (in case of malicious use).

More secure
An email (rate limited to one every 12 or 24 hours) is sent to the account email address with with a recovery link to confirm the request to reset their token. Once clicked, the token is NOT immediately removed, but instead a new message goes out letting the user know that their request has been received and acknowledged, and they have $time hours to cancel this action (again with a link to cancel it in the email).

The latter option means you both have to acknowledge the request, and it gives you time to act in case the initial entrypoint to your user was via a compromised email account.

In addition, successfully signing in to your site during the wait periods, with a valid 2fa token, should cancel the request, as you clearly have a token generator that is valid available, and can then manually reset it from your profile if needed.

This should all be tied together with one additional constant, because larger sites may have IT staff or agency partners, and managed hosts may still wish to help manage and keep things extra secure, so a constant to disable the recovery functionality should be introduced.

Is this just password recovery with more steps? Sort of, yeah, but if we ever wish to have the opportunity to propose a core merge in the future, I think it should be a requirement to help protect users from them selves where needed (we all make mistakes, and not everyone is comfortable with doing technical changes, even if they would probably be fine in doing so).

Designs

No response

Describe alternatives you've considered

No response

Please confirm that you have searched existing issues in this repository.

Yes

[kasparsd]

letting the user know that their 2fa token will be unset in $time hours, with a link to cancel the request (in case of malicious use).

This would allow anyone to unlock all configured second factors if the user doesn't take action and stop the process (even if the email second factor wasn't enabled), right?

The "More secure" approach basically force-enables the email two factor (and disables the other more secure ones that could have been enabled for the users/site) thus enabling account takeover by gaining access to users' email.

I feel like technically there is no way to enable account self-service recovery without compromising the very promise of the second factor.

How about we instead:

1. Allow super admins (and maybe individual site admins) to email users one-time login links that skip the second factor? This is similar to the suggestions above with the only difference being that it is not a self-service option.

2. AND enforce the creation of backup codes when any of the second factors are enabled for an account?

This ensures that:

1. there are practical ways for site admins to reset user accounts.

2. users are encouraged to follow the best practices by keeping a copy of backup codes. If they fail, they can always ask admins or super-admins to "unlock" their account.

[Clorith]

This presumes that sites have a super admin though. I have no numbers to back this up, but... I suspect a lot of sites are single user sites.

I totally understand the concerns, and it's something we really need to find a good solution for, that doesn't lock users out, or excessively burden hosting support I feel.

I believe backup codes are already generated when you enable any non-email second factors? (I could be wrong, if that's the case that should likely be a separate ticket though).

[Motrotz]

The "More secure" approach basically force-enables the email two factor (and disables the other more secure ones that could have been enabled for the users/site) thus enabling account takeover by gaining access to users' email.

Well, not really. Enabling E-Mail 2fa would allow an attacker to immediately sign in once the email account is compromised. This approach differs so that an attacker with email access could still initiate that process and potentially cover their tracks, but it is way harder because it takes a long time. Once the process is started the user still has to wait hours or days (user configurable, but preferrably 14 days or more to account for holidays) until email 2fa will be enabled. During this wait period, the user will be sent warning emails periodically (also configurable).

So, with a 7 day reset window, and a 12h notification interval, a user would:

1. log in with username + password
2. click "I lost access to my 2fa method"
3. receive an email to confirm they want to start 2fa recovery
4. click on "start 7 day wait period to reset 2fa"
5. receive 7 days * 24 hours / 12 hours = 14 notification emails that this process has been initiated
6. receive a final email with a link to enable email 2fa
7. click on "enable email 2fa for account XYZ"
8. log in using email 2fa

So for an attack to be successful the attacker must control the email account for days, and periodically hide their tracks. (or use filters).

Edit: Maybe let the site owner configure which roles are eligible for 2fa recovery, or set different waiting and notification periods for roles.