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}

Topical:

http://shubh.am/how-i-bypassed-2-factor-authentication-on-google-yahoo-linkedin-and-many-others/