Page MenuHomePhabricator

Implement two-factor authentication
Closed, ResolvedPublic

Description

This is a longer-term nice-to-have, but it would be good to build two-factor auth at some point. The easiest second factor is SMS, although there are various general-purpose TOTP apps available for smartphones that we could look at too.

Event Timeline

epriestley updated the task description. (Show Details)
epriestley raised the priority of this task from to Low.
epriestley added a project: Auth.
epriestley added a subscriber: epriestley.
bartus added a subscriber: bartus.Mar 18 2014, 5:07 PM
epriestley edited this Maniphest Task.Apr 15 2014, 9:16 PM

Say I use AWS to authenticate on Phabricator. And my AWS account already has 2-factor auth enabled. Does Phabricator ask for 2-factor through AWS?

No, we don't directly integrate with two-factor auth provided by any external services currently.

(For most of the larger and more security-conscious installs, Phabricator is behind a VPN and the VPN implements two-factor auth, so I don't think we've received any direct requests for this, although I'd like to make it available eventually.)

epriestley raised the priority of this task from Low to Normal.Apr 22 2014, 11:30 PM
epriestley added subscribers: zeeg, btrahan.
epriestley edited this Maniphest Task.Apr 22 2014, 11:30 PM

This is mostly an issue of implementing support infrastructure so that applications can easily prompt for "sudo" mode while doing something mundane and not have to care about which authentication factors are attached to the user's account.

We'll also need to do some work to implement the actual factors. We have good infrastructure for passwords, but will need to build things out a bit for SMS, TOTP and hardware keyfobs or whatever else we eventually support.

epriestley edited this Maniphest Task.Apr 24 2014, 1:55 AM
epriestley edited this Maniphest Task.Apr 24 2014, 7:00 PM
epriestley edited this Maniphest Task.Apr 27 2014, 3:59 AM
epriestley edited this Maniphest Task.Apr 27 2014, 6:52 PM
epriestley edited this Maniphest Task.Apr 28 2014, 12:31 AM
epriestley edited this Maniphest Task.
epriestley edited this Maniphest Task.
epriestley edited this Maniphest Task.Apr 28 2014, 4:27 PM
epriestley edited this Maniphest Task.Apr 28 2014, 5:03 PM
epriestley edited this Maniphest Task.Apr 28 2014, 5:20 PM
epriestley edited this Maniphest Task.Apr 30 2014, 11:57 AM
epriestley edited this Maniphest Task.Apr 30 2014, 1:56 PM
epriestley edited this Maniphest Task.Apr 30 2014, 4:21 PM
epriestley edited this Maniphest Task.Apr 30 2014, 9:30 PM
epriestley edited this Maniphest Task.
epriestley edited this Maniphest Task.Apr 30 2014, 10:04 PM
epriestley edited this Maniphest Task.May 1 2014, 12:45 AM
epriestley edited this Maniphest Task.May 1 2014, 2:30 AM

After D8922 lands this will work in a way that should mostly be usable in general. Future work includes:

  • TOTP seed transfer is currently manual (the user types a 16-digit alphanumeric code into their phone). It would be nice to generate QR codes instead. QR is just a bit messy to generate, and I don't want to use Google's API for it since it involves handing TOTP seeds over to them.
  • Adding SMS as an option would be nice. T920 is a blocker.
  • Adding passwords as an option might be nice. This doesn't give a very good second factor, but can enable high security mode without requiring a phone. Users could also usually use a desktop TOTP application, though.
  • There's no "print out these one-time passwords" option for factor recovery after the loss of a device. In most cases, I think administrative stripping will be sufficient, but we can see how many people lose their phones.
epriestley edited this Maniphest Task.May 1 2014, 4:24 AM
epriestley edited this Maniphest Task.May 1 2014, 1:35 PM
epriestley edited this Maniphest Task.May 1 2014, 5:23 PM
epriestley edited this Maniphest Task.
epriestley edited this Maniphest Task.
epriestley edited this Maniphest Task.

General note so it's written down somewhere:

  • The SMS implementation should be generic about the storage for SMS codes. That is, it should be storing "generic-ish, flexible, multipurpose one-time auth codes", not "sms codes" specifically.
  • Password resets should move to one-time auth codes after this infrastructure exists. This is a good technical fit and will reduce HackerOne false positives.
  • Password resets (i.e., email account recovery) should be roadblocked by two-factor.
  • One-time auth codes have a good chance of eventually being a piece of the puzzle in {T1161} and {T3117}
epriestley edited this Maniphest Task.May 20 2014, 5:49 PM
epriestley edited this Maniphest Task.May 20 2014, 6:43 PM
epriestley edited this Maniphest Task.May 22 2014, 1:41 AM
epriestley edited this Maniphest Task.May 22 2014, 5:41 PM
epriestley closed this task as Resolved.Aug 25 2014, 3:30 AM

I've been using this for a while and it seems to work well.

All the one-time token infrastructure got built and everything got moved over.

We'll do SMS after T920.