Page MenuHomePhabricator

Phabricator: Simplify the multifactor auth reset procedure
Open, MediumPublic

Description

The procedure for resetting TOTP 2nd factor authentication[1] needs improvement.

My motivation for filing this task is T231526: Reset my 2FA on this Phab account. You can read the comments on that task for a bit of background on this one.

The procedure, as it exists today, is somewhat complex. Worse than that, it may not be possible to complete the procedure. I'll quote the wiki page here:

If you lose access to your second-factor device, you must have put your user committed identity hash on your wiki user page at least one month before requesting a multi-factor authentication reset. You will permanently lose access to your Phabricator account unless you can complete the reset instructions below.

One thing that could improve the situation would be supporting pre-generated reset codes, however, that isn't currently supported in phabricator.

I would welcome any other suggestions for how we could improve this process via comments below or the talk page on the procedure's wiki page.

Event Timeline

mmodell created this task.Aug 30 2019, 4:55 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 30 2019, 4:55 PM
mmodell triaged this task as Medium priority.Aug 30 2019, 4:56 PM
mmodell added a project: Phabricator.
mmodell moved this task from To Triage to Policies on the Phabricator board.
Reedy added a subscriber: Reedy.Aug 30 2019, 6:37 PM

One thing that could improve the situation would be supporting pre-generated reset codes, however, that isn't currently supported in phabricator.

The fact phab doesn't have this seems a massive oversight. Basically, there's no way currently for a self service attempt to recover an account which the scratch tokens would provide

mmodell added a comment.EditedAug 30 2019, 6:38 PM

The fact phab doesn't have this seems a massive oversight.

@Reedy: yeah I'm inclined to look into adding this feature to Phabricator though I am not sure how it should be implemented.

Reedy added a comment.Aug 30 2019, 6:38 PM

Generate N codes, save them in a database column somewhere? :)

Generate N codes, save them in a database column somewhere? :)

Yeah, I guess that covers the core of it. Also need a UI for the user to access and save their codes, a way to regenerate them if they get used up or compromised, and a database lookup somewhere in the authentication process, and another query to invalidate codes that have been used already.

Reedy added a comment.Aug 30 2019, 6:43 PM

Re-generation and other UI-niceness is definitely a nice to have... But having them generated at enrollment, and then useable on request for a TOTP would seemingly be a MVP

Which is basically the state of it in MW atm, with requests to have the regeneration etc that doesn't involve removing 2FA and re-enabling it

I'd be intrigued to know why it wasn't implemented as such in the first place, being basically the standard way it's done everywhere else

So the question is whether this is worth the effort to implement. I'd imagine it would eventually pay for itself in time saved dealing with 2factor resets. And that is not even to mention the improvement in user experience vs. losing their account or dealing with jumping through hoops to prove their identity.

Reedy added a comment.Aug 30 2019, 6:45 PM

So the question is whether this is worth the effort to implement. I'd imagine it would eventually pay for itself in time saved dealing with 2factor resets. And that is not even to mention the improvement in user experience vs. losing their account or dealing with jumping through hoops to prove their identity.

I'd imagine it'd catch a decent % of people. It of course won't work for those that lose the scratch tokens, or never recorded them... But we can't do much about that beyond advising people on what they're doing, and they should be saving them

See also some discussion in T187256.

mmodell renamed this task from Simplify the multifactor auth reset procedure to Phabricator: Simplify the multifactor auth reset procedure.Aug 30 2019, 11:21 PM
Tgr added a comment.Aug 31 2019, 9:31 AM

I'd also suggest to have different rules for high-risk accounts (Phab admins, people in the Security ACL) compared to normal accounts, the stealing of which really isn't much of a problem.

(Using Phabricator OAuth for logging into other systems complicates things a bit, but it's only supposed to be temporary.)

(Using Phabricator OAuth for logging into other systems complicates things a bit, but it's only supposed to be temporary.)

[offtopic] Why and why is it supposed to be temporary? https://tools.wmflabs.org/phab-ban/ sounds like a good usecase, but I get that having this tool _at all_ is a hack itself, and probably should be temporary in it's longer-term sense :D.

Tgr added a comment.Sep 1 2019, 6:18 PM

Phab helper tools are not really "other systems". When used as authentication for other systems (e.g. Wikimedia Space), it's hard to judge how sensitive an account is; it could be a completely unprivileged in Phab and yet allow the user to log in somewhere else with high privileges.

That is not phab specific, tbh. I can have an account that is completelly unprivved in wiki, but being the sole login method for a privved phab account. To what extent makes that the SUL account more privved? If to any, it makes it hard(er) to judge how sensitive it is before doing an action over it. Separate problem, but same principle.

This is nothing but same situation for phab being at the other side of the wall. As a general recommendation, I think we should deem any account to be primarily an identification mechanism, which may or may not be derrived by other systems, including technical ones, and including systems that grant privileges.

An example, https://tools.wmflabs.org/wikinity/ allows certain SUL users (defined by naming them, not by adding meaning to "sysop" or something) to execute privileged action. I'm not sure how that (if any) makes the SUL account more privved/sensitive, but if Wikinity used Phabricator OAuth, it would be the same. For all accounts, we should take "reasonable measures to assure the identity is still verified".

Note that purely "comment as trusted user" is privilege by itself. A proposal made by Tgr, recognized member of the community and staff, would be interpreted differently, than the same proposal by Mr X, a totally unknown person. This is separate issue, outside of any technical privileges you may have in Phab.