I like TOTP. I use FreeOTP+ from F-Droid and I'm very happy about it in 20+ websites.. but not in Phorge.=== Example use case ===
I don't think much users use the TOTPAuth method apart me on Phabricator/Phorge. I say this since the tool is very strict (positive) but I see the majority of the people in my office who just try to disable TOTP (negative) because of this frustrating use case:
* everything is on fire, you need to quickly login and create a Task
* it asks your TOTP
* you take your TOTP appneed 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
* you copy-paste the code2. do whatever other action requiring a MFA - for example, {nav Task > Sign With MFA}
What happens if you do the second thing in less than 90 seconds:
> {F256494, size=full}
== 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.
Now. For some reason, at this point you may be in front of this window:{F312401,size=full}
{F256494}Notes: this is already implemented for the VCS password.
This happens for a lot of reasons.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:
{F312403,size=full}
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, Examples: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.
In my opinion,Somebody can says that 3 minutes is a better default than 1. Anyway, if there is no much consensus on increasing this limit (even if I would like to understand if somebody is happy about the current default), it would be just OK to allow to increase the default, introducing a small side-wide configuration, to allow me to set it to `3` and love TOTP againI don't see much consensus on increasing this limit (even if I would like to understand if somebody is happy about the current default).
To be honest I'm not totally sure about what makes the current implementation so strict, but probably hereHere 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;
}
```
I've also found thisHere 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
== Possible Actionable Proposals ==
When entering the MFA, let's stay in "High Security" mode for at least $the_duration_of_the_token_cycle (that should be 90 seconds).
(If you need to test the "High Security Mode", enables MFA and set a VCS Password.