Page MenuHomePhabricator

Update documentation for MFA, including administrator guidance
ClosedPublic

Authored by epriestley on Jan 25 2019, 5:32 PM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Mar 28, 8:35 AM
Unknown Object (File)
Sat, Mar 23, 5:51 PM
Unknown Object (File)
Sat, Mar 23, 5:51 PM
Unknown Object (File)
Feb 18 2024, 9:04 AM
Unknown Object (File)
Feb 11 2024, 7:23 PM
Unknown Object (File)
Feb 9 2024, 1:00 PM
Unknown Object (File)
Feb 3 2024, 9:01 PM
Unknown Object (File)
Feb 1 2024, 5:58 PM
Subscribers
None

Details

Diff Detail

Repository
rP Phabricator
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

amckinley added inline comments.
src/docs/user/userguide/multi_factor_auth.diviner
81–83

"an authorization"

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

89

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.

96

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

124

"sensitive" vs "high security"

145

"you can require all users to add MFA"

This revision is now accepted and ready to land.Jan 26 2019, 7:15 PM
src/docs/user/userguide/multi_factor_auth.diviner
89

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 admin.phacility.com 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.

  • 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.