Page MenuHomePhabricator

Figure out MFA in the cluster
Open, NormalPublic


We received a real support request to strip MFA, so should figure out how to let administrators strip MFA in the cluster.

The simplest approach is to provide access to auth strip from the console. However, this means that an attacker who compromises an administrator account that has MFA on an instance but no MFA on their cluster account can strip the instance MFA.

We can require encourage administrators to set up cluster MFA, but then we can't verify their identities if they need that stripped.

Some approaches for this might be:

  • Implement backup codes (T6549) -- but this only mitigates the issue.
  • Implement SMS MFA -- this is less secure than TOTP but also easier to use and less likely to get lost (hopefully).
  • Warn users that we do not strip MFA for any reason and they must retain their backup codes.
  • Creative out-of-band stuff? Like we could call the company if they have a phone number listed somewhere, but there's probably no side channel that we can employ in a reasonable number of cases.
  • Timed unlocks (some discussion in T6549) or something in that vein.
  • If we could accept payments from anonymous users, we could have users make a $1 payment with the same card to verify that they possess the card (or a card in the company name or their real name). This is how USPS verifies identity for address changes. We can't actually see the card number, but name + 4 digits is pretty compelling. However, they can't currently make a payment without logging into their account.

Revisions and Commits

Restricted Differential Revision

Event Timeline

epriestley raised the priority of this task from to Normal.
epriestley updated the task description. (Show Details)
epriestley added a project: Phacility.
epriestley moved this task to Do After Launch on the Phacility board.
epriestley added a subscriber: epriestley.

Do we require admins have MFA already by default on Phacility?

No. We do perform MFA checks if they enable it, but we don't currently require it (and don't have UI hints to suggest that they configure it).

This is sort of the blocker for that, since I'm hesitant to get everyone on MFA when we don't have a plan on stripping/resetting. I'd probably want to show a suggestion to users with no MFA and at least one administrated instance ("Hey, configure MFA for extra security when you have a chance.") if we had a clearer direction here.

I also guess I can build the actual instance-strip operation regardless of the central-account-strip operation, since if administrators configure only instance MFA then central MFA compromise likely allows an attacker some kind of access anyway (at a minimum, they can add an account they control to the instance as a member, which is likely nearly as bad as compromising an administrative account fully).

Yeah I assume we want admin to have the beefiest set of protection.

epriestley added a revision: Restricted Differential Revision.Mar 20 2015, 9:54 PM
epriestley added a commit: Restricted Diffusion Commit.Mar 23 2015, 4:11 PM

One idea is that we could let you designate peers (either explicitly, or implicitly by sharing administrative control with them? -- but probably explicitly) who are permitted to strip your MFA tokens.

That is, the workflow would be:

  • UI says "If you lose your phone and your MFA backup codes, you won't be able to access your account. You can designate peers who you trust to remove MFA from your account. If you lose your phone, you'll be able to ask them for help to regain access.".
  • I go designate that I trust you to strip MFA.
  • I lose my phone.
  • I go over to your house and give you the secret handshake, then say "Please strip my MFA."
  • You log in, strip my MFA, and then I'm back in.

This generally doesn't let an attacker expand access (at best, they can compromise accounts sideways, which isn't too valuable) and is hands-off for us and legitimately pretty secure. Seems reasonably easy for users to understand, too. So I generally like this approach.