Page MenuHomePhabricator

Update documentation for MFA, including administrator guidance

Authored by epriestley on Jan 25 2019, 5:32 PM.


Diff Detail

rP Phabricator
Automatic diff as part of commit; lint not applicable.
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

epriestley created this revision.Jan 25 2019, 5:32 PM
epriestley requested review of this revision.Jan 25 2019, 5:34 PM
amckinley accepted this revision.Jan 26 2019, 7:15 PM
amckinley added inline comments.

"an authorization"

Also, "master key"? Maybe just talk about QR codes here?


Out of scope, but do we ever intend to build out recovery codes? Right now recovery is just "have an admin strip the factor" so I don't think it's a big deal; just curious if this is on the roadmap.


I don't care either way, but we should be consistent about "sensitive action" vs "high security action".


"sensitive" vs "high security"


"you can require all users to add MFA"

This revision is now accepted and ready to land.Jan 26 2019, 7:15 PM
epriestley added inline comments.Jan 26 2019, 7:56 PM

Maybe (T6549). I think it mostly serves to reduce the support burden on administrators, and no one's really complaining about that today.

For Phacility, attackers will just say "I also lost / didn't save my backup codes". I don't think there's a case where we'd say "okay, we'll strip" today, but would say "sorry, we won't strip" if we had backup codes, so this doesn't do much to improve cluster security.

I think the quorum approach (T7639 / T9515) is more promising on both the "support burden" and "actual security" dimensions -- in basically every case, I'd change "okay, we'll strip" to "okay, we'll modify your quorum to include the other instance managers and you can ask them for help getting access to your account" if we had the quorum feature. Pretty much the only exception is one-user installs.

(A short term "fix" for this is that I'm planning to deprecate MFA, but that's because users keep enrolling themselves by mistake, not because instance managers are losing their phones.)

If a customer install was like "I'm an administrator and spend all day verifying secret handshakes and stripping factors, can we make this easier" I'd probably still try to push toward quorum over backup codes -- I think quorum is just generally a better approach here on every dimension. Maybe that'll turn out to be untrue after we build it, but it seems like it's easier for users, more secure, gives administrators more flexibility in not making a call with limited information, can't be lost or stolen or observed by an attacker, etc. And you can stage attacks on it for fun to keep everyone on their toes.

I think it's only worse if users turn out to be wildly eager to approve absolutely anyone's account recovery without verification, and if that's true it's probably good that you can discover it by staging an attack, since it represents a generally poor attitude toward security.

epriestley updated this revision to Diff 47851.Jan 26 2019, 7:57 PM
  • Just describe QR codes since that's how it works in basically every case in practice.
  • Be consistent about "high security" vs "sensitive".
  • Wordsmithing.
This revision was automatically updated to reflect the committed changes.