Example use case

• everything is on fire
• you need to quickly login and do something else requiring MFA (for example, reset your VCS password)

→ you die :D

For some reasons you cannot perform "two normal MFA things" in less than 90 seconds. Every following action could require an additional 90 seconds of wait.

Steps to reproduce

1. do login with MFA
2. do whatever other action requiring a MFA - for example, Task → Sign With MFA

What happens if you do the second thing in less than 90 seconds:

Possible Actionable Proposals

Premising that we already have some actions that enables an "High Security" mode for indefinite time, for example while changing a VCS password, probably we could think about this system, that is not activated by default after login.

Note that the current implementation of the "High Security Mode" already allows the user to disable it anytime.

Proposal 1 - Enable "High Security Mode" for more actions (e.g. after login)

Proposing to enable "High Security Mode" for example after the login could be useful, since of course after a login the user would like to do an indefinite number of things.

Notes: this is already implemented for the VCS password.

Pro: very simple to implement.

Cons: ?

Proposal 2 - Introduce a default "High Security Mode" with auto-expiration

A kind of compromise. If we don't like to activate indefinite "High Security Mode" for more actions, why not enabling that for just its normal cycle - 90 seconds?

MOCKUP:

Notes: when the timer runs out, you don't die: you just have to re-enter a MFA for more actions.

Pro: it makes semantically sense.

Cons: ?

What is NOT covered by this Task

The slowness of the user in taking the token in hand is probably not something we can fight. As speck says, we could add a warning "Get ready, take token in hand" to avoid situations where:

• You took more than 59.9 seconds
• Phorge/Phabricator webserver has the wrong clock by 20+ seconds
• your mobile app has the wrong clock by 20+ seconds
• you tried to login at 06:00:50 AM generating the token at 06:01:10 AM
• a weird combination of these things

To avoid this frustrating issue, I think most banks probably have a time window of at least 3 minutes (-1, current, and +1) and not just 60 seconds, since they want to prevent users from just delivering weird complains about the TOTP token expiration, and banks also want to prevent users from just asking to disable TOTP so they don't waste their time anymore, but also keeping this security measure on as much as possible.

Somebody can says that 3 minutes is a better default than 1. Anyway, I don't see much consensus on increasing this limit (even if I would like to understand if somebody is happy about the current default).

Here there is the most-relevant part:

https://we.phorge.it/source/phorge/browse/master/src/applications/auth/factor/PhabricatorTOTPAuthFactor.php$424-429

	  private function getTimestepWindowSize() {
	    // The user is allowed to provide a code from the recent past or the
	    // near future to account for minor clock skew between the client
	    // and server, and the time it takes to actually enter a code.
	    return 1;
	  }

Here a related comment in a 2018 commit message that it's about this strictness:

...
Reduce the TOTP window from +/- 2 timesteps (allowing ~60 seconds of skew) to +/- 1 timestep (allowing ~30 seconds of skew).
...
rP3da9844564cf7f93916e420ecae64a4faf15a2d7