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.