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.
Description
Revisions and Commits
rP Phabricator | |||
D9252 | rPf1534e6feb6a Make password reset emails use one-time tokens | ||
D9217 | rPcac61980f904 Add "temporary tokens" to auth, for SMS codes, TOTP codes, reset codes, etc | ||
D8910 | rP68023e64a922 Document multi-factor authentication | ||
D8924 | rPa04e138ae247 Minor cleanup of some session code | ||
D8923 | rPe14695821758 Generate QR codes for TOTP tokens | ||
D8922 | rP50376aad04d2 Require multiple auth factors to establish web sessions | ||
D8921 | rP3fde02004968 Make many actions require high security | ||
D8911 | rP23e654ec2bc8 Rate limit multi-factor actions | ||
D8909 | rP535cfa3ebebe Add `bin/auth list-factors` and `bin/auth strip` to remove multi-factor auth | ||
D8886 | rPa017a8e02b51 Make two-factor auth actually work | ||
D8875 | rP17709bc1674e Add multi-factor auth and TOTP support | ||
D8871 | rP3f5a55fa6e5a Let users review their own account activity logs | ||
D8856 | rP320be1a1b8d4 Modernize user activity logs (ApplicationSearch, policies) | ||
D8851 | rPf42ec84d0c6b Add "High Security" mode to support multi-factor auth |
Status | Assigned | Task | ||
---|---|---|---|---|
Wontfix | epriestley | T4806 Give installs more control over session expiry / prompt for reauth before taking security actions | ||
Resolved | epriestley | T4398 Implement two-factor authentication | ||
Resolved | epriestley | T920 Provide SMS Support |
Event Timeline
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.)
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.
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.
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}
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.