Upstream: https://we.phorge.it/T15078
Having an app like Google Authenticator for doing two factor auth is common but it's also prone to getting "lost" more easily, as is evident from the trail of Phabricator tickets about 2FA resets. Phones get damaged or lost or changed etc. Can we tie 2FA on phabricator to email or SMS instead (or add that as an option)?
I don't really know what kind of work will be involved with that. This is low priority. :)
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Declined | None | T231667 Phabricator: Simplify the multifactor auth reset procedure | |||
| Open | Feature | None | T187256 Add another way of two factor auth to Phabricator other than TOTP (SMS, email, etc) |
Phabricator now supports SMS MFA, although we strongly discourage using it because it has a long history of being compromised by attackers (see https://secure.phabricator.com/T13241).
(Perhaps see also https://www.youtube.com/watch?v=lc7scxvKQOo.)
We also now support Duo, although Duo is a weird enterprise sales funnel of a company and probably not suitable in this use case, even though their product seems like it may be a least-bad technical option today.
We plan to support U2F in the future (see https://secure.phabricator.com/T8787) but I'm not satisfied that the technology is ready yet (mostly because of limited Safari/Firefox support). WebAuthn seems to be headed in the right direction, though, so I expect this may be supported before too long.
Email has poor security properties as a second factor and I don't imagine supporting it upstream, although you could conceivably copy/paste the SMSAuthFactor to create a similar EmailAuthFactor if you're comfortable with extremely weak "MFA".
We may support recovery codes in the future (see https://secure.phabricator.com/T6549) but they don't do much to improve the security of the MFA support interaction (an attacker trying to convince an administrator to strip MFA from a victim's account will just say they lost or didn't save their recovery codes), and I suspect they won't do much to reduce the total support burden of MFA (since at least some users won't save or be able to find their recovery codes, and I suspect this is most/many/nearly-all users). Maybe users are better about this than I'm imagining, but my assumption is that this would maybe reduce the burden by like 1/3?
If anyone has a pointer to data suggesting I'm way off on this and users are actually good about recovery codes, I'd consider that to be a good argument for implementation (for example, an article where some company says "every day, 900 users use recovery codes and 100 users write support about MFA, so recovery codes solve about 90% of the support burden").
I currently plan to implement a "Quorum" approach, where you can ask other users to vote you back onto the island (see https://secure.phabricator.com/T9515) -- basically, self-recovery by getting other users to vouch for you. This may or may not fare well in the general case but is possibly reasonable for WMF.
I also imagine adding more options for selecting who may/must configure different types of MFA (for example: staff must configure strong MFA like TOTP, other users may configure weak-but-easy-to-reset MFA like SMS). See https://secure.phabricator.com/T6115.
@epriestley we have similar challenges with MediaWiki. Esp. in the context of Wikipedia, where we simply have too little info to easily do recovery if a 2FA key is lost (which happens and yes, I think we have more cases where people either never printed or since lost their recovery keys, than we have cases where the recovery keys are actually used).
I left some ideas in T180896#3798818 about technical measures, checks and logging that we could possibly apply to inform the functionaries (or a quorum of them) when making a decision about resetting MFA. Maybe there is something useful among those ideas for you guys.
Thanks for working on things like this. It is important !
There's some discussion of the risks of SMS 2FA (in the context of using it for MediaWiki) in T150902: SMS based 2FA.