You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The topic was discussed recently by @sybrew and me. We thought it would be great to get a step ahead here and propose some clear solutions on how to move forward with account recoveries.
This is a tracking issue for making it safer and easier to recover a WordPress account after a user loses their second factor, without weakening the second-factor promise for everyone else. It captures the design discussion and links the concrete work items as sub-issues.
The core tension
As @kasparsd put it in #621: "technically there is no way to enable account self-service recovery without compromising the very promise of the second factor." Any self-service reset an honest user can trigger is, by definition, a path an attacker who controls the same inputs (usually the email inbox) can also trigger.
So the goal is not "a reset anyone can do with zero risk." It is a layered set of options where each site picks the trade-off it is comfortable with: the operator-side options carry little to no new risk; any self-service option must be opt-in and deliberately slow.
A site-wide "disable 2FA for everyone" kill-switch is intentionally out of scope — disabling 2FA for everyone because one person is locked out throws away the protection of every other account. Recovery must target the single affected user.
No self-service path for a single-user site whose owner lost their second factor and has no second admin.
Potential solutions are discussed here Account recovery after losing 2fa key #621
Summary
The topic was discussed recently by @sybrew and me. We thought it would be great to get a step ahead here and propose some clear solutions on how to move forward with account recoveries.
This is a tracking issue for making it safer and easier to recover a WordPress account after a user loses their second factor, without weakening the second-factor promise for everyone else. It captures the design discussion and links the concrete work items as sub-issues.
The core tension
As @kasparsd put it in #621: "technically there is no way to enable account self-service recovery without compromising the very promise of the second factor." Any self-service reset an honest user can trigger is, by definition, a path an attacker who controls the same inputs (usually the email inbox) can also trigger.
So the goal is not "a reset anyone can do with zero risk." It is a layered set of options where each site picks the trade-off it is comfortable with: the operator-side options carry little to no new risk; any self-service option must be opt-in and deliberately slow.
A site-wide "disable 2FA for everyone" kill-switch is intentionally out of scope — disabling 2FA for everyone because one person is locked out throws away the protection of every other account. Recovery must target the single affected user.
Gaps today
No first-party WP-CLI command — operators must edit the database or un-check options as a second admin.
Proposal is available at #233: Add WP-CLI support with
wp two-factorcommands #905 (Issue Add wp-cli support #233)No supported
wp-config.phplever to bypass 2FA for a locked-out account.Proposal is available at add wp-config support to disable 2fa for a user #908
No self-service path for a single-user site whose owner lost their second factor and has no second admin.
Potential solutions are discussed here Account recovery after losing 2fa key #621
Recovery codes are optional, so the one self-service path that exists is often unavailable when needed.
Could be implemented as part of Setup Onboarding Login-Flow (for Enforce 2FA) #813
No "running low on recovery codes" warning — users are only notified once they are completely out.
Proposal is available at #906: add early notice for soon exhausting recovery codes #907