Following more or less what https://wikitech.wikimedia.org/wiki/Password_reset/Confirming_identities describes seem a fair solution which is basically 'make sure they are the person who owns the account' which does list 'Other accounts known to be controlled by the user (bot accounts) can make a requesting edit'. So here, if the MediaWiki or LDAP account is linked, confirming the identity via those methods seems the best.

In T85706#952759, @JohnLewis wrote:

Following more or less what https://wikitech.wikimedia.org/wiki/Password_reset/Confirming_identities describes seem a fair solution which is basically 'make sure they are the person who owns the account' which does list 'Other accounts known to be controlled by the user (bot accounts) can make a requesting edit'. So here, if the MediaWiki or LDAP account is linked, confirming the identity via those methods seems the best.

That can't really work out as an effective means of disabling 2factor. The difference is that the linked accounts (mediawiki and ldap) are the validation mechanisms for Phabricator. So while it is possible to have 2 passwords, those passwords are not going to be different for the external account than they are when authorizing via the external account in the Phabricator context.

An example, I set 2factor and lose my phone. If logging into my medawiki account because it is linked and setting some value in my profile is sufficient authentication to remove 2factor from my Phabricator account then the 2factor was completely useless. It is the same password in both cases. If I lost my mediawiki password someone in this case can also nullify and access my 2factor protected account by design. Even setting multiple passwords across external providers is not a truly valid approach to recovering 2factor since by definition is a less strenuous measure to meet to remove the protection than it is to use it.

The only mechanism I can see working here is to validate the email associated with the account is actually the user in question.

Yeah, to reset 2fa, we really need a second identity proof other than the signin.

• We should be issuing scratch tokens when 2fa is setup, so that's what users should use
• Like on https://wikitech.wikimedia.org/wiki/Password_reset/Confirming_identities, a committed identity is best. That would hard to forge without totally compromising the target.
• For developers, we can probably say their gerrit key is a second factor-- so if they can make a gerrit commit using their linked ldap account, that would work for me.
• If they are well known on irc, and have an identity with freenode, I think that would be a sufficient check
• I don't really like email, since email lets you reset the mediawiki password, so that basically reduces to "controls the target's email" (unless their phab account is linked to different email from their mediawiki account)

In T85706#955720, @csteipp wrote:

• I don't really like email, since email lets you reset the mediawiki password, so that basically reduces to "controls the target's email" (unless their phab account is linked to different email from their mediawiki account)

In hindsight I was thinking this and described it poorly and also I think probably won't work for most users, if you don't archive off your one-time in case of emergency. Probably, you are not going to pre-add an email for the purposes of 2factor reset. So yeah :)

FWIW, we aren't issuing anything for this. Phab supports 2factor via google authenticator (etc) and some users have done this of their own accord.

In T85706#955720, @csteipp wrote:

• If they are well known on irc, and have an identity with freenode, I think that would be a sufficient check

This also reduces to 'control the target's email', as freenode passwords can also be reset that way. Checking whether their hostname is known would actually be a better option, as that requires access to the internet connection in addition to a password.

I'd like to pose a different question, though: why do we provide a 2fa option in the first place? I would not consider phabricator a high-value target, so I'm not sure if it doesn't just cause more hassle than it solves.

It is a high value target when we consider the operational data (serial numbers / vendor contacts / support contracts / etc)

For the migrated RT content especially, but limiting who can shoot themselves in the foot via 2factor would be nice.

In T85706#955720, @csteipp wrote:

• We should be issuing scratch tokens when 2fa is setup, so that's what users should use
• For developers, we can probably say their gerrit key is a second factor-- so if they can make a gerrit commit using their linked ldap account, that would work for me.

For me that are two good methods. A question here: I couldn't found an information on the helppage of the 2FA plugin for phab: is it possible to configure it to generate a set of emergency codes?

To Gerrit commit: i think, that the 2FA function is better known for people working on phabricator in a lot of tasks, which are (maybe) developers most of the time. So this shouldn't be a problem to commit to a project (maybe just a test project or something else) with your ldap account.

Ah, I had not considered that. Looking through the Phab source, it's not entirely trivial to limit TOTP to WMF employees, but it might be possible to subclass PhabricatorAuthFactorTOTP and hook into the validation routine.

Providing a reset policy that distinguishes between secure and non-secure accounts is probably easier.

In T85706#955926, @valhallasw wrote:

Ah, I had not considered that. Looking through the Phab source, it's not entirely trivial to limit TOTP to WMF employees

even if it was trivial/possible I don't think it would be limited to just WMF employees

Now that I think of it, the Gerrit commit solution also isn't perfect either; one could reset the wikitech password, then log in to Gerrit and change the keys there (or even just push a changeset over https).

SSH keys look OK on first glance, but also have issues: It's impossible to check which ones are identity-proving and which ones are used for, say, automated deployments. In addition, there has to be a check for newly-uploaded keys.

Note to myself: I should sort this out and document as this problem might get more common (T89605).

In T89605#1043133, @Aklapper wrote:

In general we do not advertise using this functionality.

Please paste your committed identity (SHA) on your user page. Afterwards, please follow the steps in T87495#1028549.

Note that the committed identity should have been provided before the 2fa reset request (preferrably far before) -- if the password is compromised, the committed identity can also be provided by the attacker.

Can we possibly set up a different method other than this? I understand the community really loves this "committed identity" approach, but it is really deficient for a number of reason:

1. It depends on the security of the passphrase being used. At this rate, it defeats the point of 2FA, which is to have a barrier to authentication in addition to passwords. It doesn't really help if the attacker just has to guess a second password.
2. It relies on publishing the identity on a wiki-page. What if the account is compromised and the attacker changes the identity? How can this be distinguished from the user legitimately changing their committed identity?
3. Many pages encourage putting personal information into the committed identity, which could be a problem if a user is tricked into exposing their identity to a third-party.

Maybe for an on-wiki identity these risks are OK, but for Phabricator, especially for accounts that have access to sensitive information like security bugs, I do not think it suffices. We need a method that is crypto-systemically secure.

Both the committed identity and 2FA prove one thing: that someone (who either provides the SHA hash, or sets up 2FA) is in control of that account at that time. They both serve to allow to distinguish an attacker who has the password now from the person in control of the account before (when setting up the CI/2FA).

As I mentioned, this means the committed identity has to have been set up some time ago: we have believe that the person who set up 2FA was the same person who set up the CI. If the CI was set up before 2FA, this is clearly the case (whoever set up CI was the original user), for a CI set up after 2FA, there has to be some 'quarantaine' period.

To specifically respond to your points:

1. There is only a single passphrase here, namely the SUL passphrase. This passphrase should be considered compromised in this discussion.
2. The wiki acts as a third party that provides a proof of time, which is all that is required. The attacker could change the CI, but in the same way, the attacker could have set up 2FA to block the original user.
3. No, it's not, because the CI requires a specific, and undisclosed, combination of those pieces of personal information.

especially for accounts that have access to sensitive information like security bugs,

Not really. There are many accounts without 2FA enabled who have access to those bugs, so 2FA does not save you there. Groups that *have* to use 2FA will typically consist of WMF employees (who can just show their face) or the NDA group (for which I assume the WMF has out-of-bound contact information).

I've created https://secure.phabricator.com/T7309 to address the problem of scratch tokens.

Thanks everybody for the comments and helping me understand the problem. Appreciated!

In T85706#1043501, @valhallasw wrote:

Note that the committed identity should have been provided before the 2fa reset request (preferrably far before) -- if the password is compromised, the committed identity can also be provided by the attacker.

Right, very good point. The template page explicitly says it is to "prove that you are the person who was in control of your account on the day this template was placed".

We won't find a technically perfect solution, hence looking for a feasible/acceptable solution for Wikimedia Phabricator until upstream tackles backup codes.

Please comment / feel free to rephrase:
"In order to request a multi-factor authentication reset on Wikimedia Phabricator, you must have put your user committed identity hash on your wiki user page at least one month before requesting such a reset. Until upstream offers backup codes for multi-factor authentication, we generally do not encourage using multi factor authentication on Wikimedia Phabricator, especially not within the first month after publishing your user committed identity hash on your Wikimedia wiki user page as your reset request might get denied."

I would like to add the following section to the "Advanced" section in https://www.mediawiki.org/wiki/Phabricator/Help#Creating_your_account and link to that section from https://wikitech.wikimedia.org/wiki/Phabricator .
"Sounds okay given the technical constraints" comments welcome:

"If you consider to use multi-factor authentication on Wikimedia Phabricator: Until upstream offers backup codes for multi-factor authentication we do not encourage using multi factor authentication on Wikimedia Phabricator, especially not within the first month after publishing your user committed identity hash on your Wikimedia wiki user page. If you still want to use it and ever lose your access, 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 in a task in Phabricator, otherwise your reset request might get denied."

Instead of ", otherwise your reset request might get denied." I would say something more harsh and arguably realistic like

otherwise you **may** __never__ be able to recover your account.

That puts the onus on the user for both diligence and consequences a bit more. Otherwise cool.

• Created https://www.mediawiki.org/wiki/Phabricator/Help/Two-factor_Authentication_Resets with warning text and instructions
• Linked to it from mw:Phabricator/Help with warning text
• Linked to it from wikitech:Phabricator

Closing as resolved.
Thanks everybody!

Reopning as the current policy at https://www.mediawiki.org/wiki/Phabricator/Help/Two-factor_Authentication_Resets
doesn't make sense if you cannot log into Phab anymore.

In T85706#5003286, @Aklapper wrote:

In T85706#1805699, @Aklapper wrote:

Reopning as the current policy at https://www.mediawiki.org/wiki/Phabricator/Help/Two-factor_Authentication_Resets
doesn't make sense if you cannot log into Phab anymore.

After https://www.mediawiki.org/w/index.php?title=Talk:Phabricator/Help/Two-factor_Authentication_Resets&diff=next&oldid=2799102 I edited

• https://www.mediawiki.org/wiki/Phabricator/Help/Two-factor_Authentication_Resets
• https://wikitech.wikimedia.org/wiki/Phabricator#Removing_Two_Factor_Authentication

and I think we are fine here.

The mediawiki page says it's outdated and points to this phab task - should that be removed?