Page MenuHomePhabricator

Make conduit more secure
Closed, DuplicatePublic


Root Problem

Phabricator can be configured to require multi-factor auth to log in to the web UI. However, Conduit API access is single-factor, requiring only an API (or CLI) token to access. We'd like to limit the effectiveness of a compromised API token.

Potential solution

Conduit tokens already have an expires field, though I don't believe there's currently a way to set it. It'd be useful to be able to enforce a global key-expiration length specified through a config value.

Event Timeline

jcox added a subscriber: Restricted Project.

Can you outline the attack scenario or scenarios you're concerned about?

I worry that "require users to go through the web login workflow every 24 hours" will be both cumbersome (for users) and ineffective (attackers who compromise a session have up to 24 hours to execute an attack, more or less unchallenged).

I suspect we can do better than this by anticipating attacks more narrowly. In particular, we can do a mixture of these things:

  • Require CLI MFA.
  • Expire tokens.
  • Expire MFA on tokens.
  • Limit token permissions.
  • Bind tokens to IP addresses.
  • Bind tokens to client secrets.
  • Use SSH keys to authenticate.

In particular, if you already have satisfactory protections on SSH keys, perhaps T550 (which sort of works today, but could be made more efficient) is the shortest pathway forward, coupled with the ability to disable HTTP access to Conduit for non-cluster clients. Then this is reduced to a problem which Security is already responsible for.

This seems like a good plan to me, we're just checking in that this isn't totally outside the realm of possibility while we plan some super secret changes to our instance.

Cool. For context, stuff I expect to do upstream, sooner or later, since I consider it unambiguously good (just not necessarily high priority):

  • Conduit over SSH (T550).
  • Granular token permissions for all session/token types (OAuth, Conduit, etc) so you can issue read-only tokens or tokens with limited access (roughly, T7303).

Stuff I think is reasonable but wouldn't necessarily do if no one cares:

  • Binding sessions/tokens to IP addresses (some discussion in T4842).
  • Maybe some form of CLI MFA for pushes or other operations? e.g., You must enter your MFA token to push code. This would have similar semantics to web-based MFA: enter a code to take a "dangerous" action.

Stuff I'm less keen on because I'm not sure it really defuses any practical attacks:

  • Generally, session/token/MFA time limits (T4806) -- any duration which is long enough to not burden users should also be long enough for a dedicated attacker.
  • Any mitigation which has zero plausible scenarios it actually lines up well against (see T9770, D10176).

I'm going to merge this into T550 since it sounds like that's the immediate way forward, at least.