Page MenuHomePhabricator

Determine policy for Phabricator multi-factor authentication reset requests
Closed, ResolvedPublic

Description

How to reset 2FA on Phab is documented at https://wikitech.wikimedia.org/wiki/Phabricator. However, it does not mention any policies on *when* it could be reset, and what forms of authenticating the request are valid.

I performed one for @Florian just a while ago, with an edit made by an attached account containing a secret I provided the requesting nick on IRC being the means of authentication. However, since phab has 2FA but mw.org does not, if we agree to use this method indiscriminately it essentially nullifies the use of 2FA (anyone with possession of just the password can get a reset done this way).

I can not also think of any other method to request a reset that does not involve terrible horrible vogony things (such as 'mail us a copy of your passport').

Having this policy decided and written down would be really useful for the next person who is requested to do a reset :)

Event Timeline

yuvipanda updated the task description. (Show Details)
yuvipanda raised the priority of this task from to Needs Triage.
yuvipanda added a project: Phabricator.
Aklapper renamed this task from Determine policy for Phabricator 2FA reset requests to Determine policy for Phabricator multi-factor authentication reset requests.Jan 2 2015, 5:48 PM
Aklapper triaged this task as Normal priority.
Aklapper set Security to None.
Aklapper added a subscriber: chasemp.
Florian added a subscriber: Florian.Jan 2 2015, 5:49 PM
Krenair added a subscriber: Krenair.Jan 2 2015, 5:49 PM

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.

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.

csteipp added a subscriber: csteipp.Jan 5 2015, 6:40 PM

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)
chasemp added a comment.EditedJan 5 2015, 6:46 PM
  • 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.

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

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

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.

Qgil moved this task from To Triage to Need discussion on the Phabricator board.Jan 12 2015, 10:23 AM

In T87495#1028549 the affected user had a "user committed identity" template at the bottom of her/his user page.
After checking that it was added to the user page form the user's account (History tab) and checking the linking via OAuth on the user page in Phabricator, the user was asked to provide the secret string in a private Paste in Phabricator so Phab admins could verify it.

Does that sound like an acceptable and reasonable appraoch?
If yes, I am happy to document it on https://wikitech.wikimedia.org/wiki/Phabricator .
If not, which problems did I ignore?

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

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

zhaofengli added a subscriber: zhaofengli.

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!

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

Aklapper raised the priority of this task from Normal to High.Feb 24 2015, 10:06 AM

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.

Closing as resolved.
Thanks everybody!

Aklapper closed this task as Resolved.Feb 25 2015, 5:40 PM

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.

Restricted Application added a subscriber: scfc. · View Herald TranscriptNov 14 2015, 5:20 PM
Aklapper reopened this task as Open.Nov 14 2015, 5:20 PM
Aklapper lowered the priority of this task from High to Low.
Aklapper removed Aklapper as the assignee of this task.
Restricted Application added a subscriber: TerraCodes. · View Herald TranscriptJul 2 2016, 7:33 PM