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

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.

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

In T231667#5454888, @Reedy wrote:

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.

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.

In T231667#5454898, @mmodell wrote:

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.

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.)

In T231667#5455918, @Tgr wrote:

(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.

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.