Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Revalidation: Prompted immediately after setting up 2FA #572

Open
dd32 opened this issue May 25, 2023 · 0 comments
Open

Revalidation: Prompted immediately after setting up 2FA #572

dd32 opened this issue May 25, 2023 · 0 comments
Labels
Milestone

Comments

@dd32
Copy link
Member

dd32 commented May 25, 2023

Describe the bug

The revalidation feature added in #529 is somewhat not ideal for a multitude of reasons, but one of the biggest pain points is that it's possible to setup a 2fa method and be prompted to revalidate instantly.

This occurs as there was code added to flag a session as being 2fa when the provider is enabled, but this is not when a provider is actually configured.

This is partly due to the way the user-interface works, with providers being able to be in 3 states for a user: Not Enabled, Enabled (but not usable), and Available (Enabled, and configured).

For some providers, such as TOTP, the flow can be either: Not Enabled -> Available or Not Enabled -> Enabled -> Available depending on whether the TOTP client is configured before enabling it, or after enabling it.

For some providers, such as Email or Dummy, there is no real Enabled state as they go directly from Not Enabled -> Available in all situations.

The way I've approached this on WordPress.org WordPress/wporg-two-factor#186, is to set the 2fa settings after a provider is configured (for TOTP this is when they key is saved, and when a key is added for WebAuthn). This works for custom implementations like ours, but this doesn't translate directly to the Two-Factor plugin or how it's used.

The WordPress.org approach could potentially work however, if something like #526 was implemented, we could simply hook into the actions like ( provider.enabled OR provider.configured ) => Check if provider.is_available_for_user THEN set-as-2fa'd

Steps to Reproduce

  1. Enable TOTP
  2. Save (Note that the next page doesn't have it as checked, but that's irrelevant for us right now)
  3. Wait 11 minutes (ie. Longer than the 10minute grace time, but shorter than the 2*$grace time of 20mins)
  4. Setup TOTP
  5. Reload the page (Do not re-check the checkbox for TOTP, do not update profile, reload)
  6. Need to revalidate still, even though you JUST setup TOTP.

This is not very visible on the Two-Factor UI, and seems like an edge-case, but is much more visible with other providers or other plugins that use the Two-Factor API such as https://github.com/WordPress/wporg-two-factor eg: WordPress/wporg-two-factor#173 WordPress/wporg-two-factor#179 - The issue with the downstream project was partly a bug in the implementation there, but partly due to the above edge-case being triggered.

Screenshots, screen recording, code snippet

Screen.Recording.2023-05-25.at.6.35.36.pm.mov

Environment information

No response

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

Yes

Please confirm that you have tested with all plugins deactivated except Two-Factor.

Yes

@dd32 dd32 added the Bug label May 25, 2023
@dd32 dd32 added this to the 0.9.0 milestone May 25, 2023
@jeffpaul jeffpaul modified the milestones: 0.9.0, 0.10.0 May 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants