Security concern with allowing Terminal complete access to my 1P account via op CLI

Hi bahamas​ 

I appreciate your thoughts here. 

I think the difficulty is whether the risk being discussed can be effectively mitigated without creating substantial friction for end users.

If I understand what you're suggesting, you're saying the 10 minute session timeout leaves all secrets vulnerable on a compromised device because you can `op item list....` without authentication for 10 minutes. 

Whereas if the session closed immediately upon the CLI executing your command, as I believe you are proposing, only the retrieved value would be vulnerable in the threat scenario you're outlining. 

If my understanding of your situation and hypothetical threat scenario is correct, I do not believe there is an effective way to mitigate that risk. 

Risk mitigation

I am not certain that mitigating this threat scenario is possible, nor would mitigating it (if possible) provide meaningful protection against an attacker capable of exploiting it. 

• The scenario you describe involves a device compromised "in some way". At a minimum, to execute the hypothetical attack you describe, the attacker needs to be able to obtain values from your terminal, run commands in your terminal, or read your device's memory. 
  • An attacker with that level of access to your device may not ever engage in the described attack because they'd have sufficient control of your system to obtain other valuable information including information from 1Password. So closing this door may be closing a door nobody was going to break into anyway.  If they attempted to break into this door and we've managed to effectively prevent that, the attacker has the access they need to access other processes on your system, such as 1Password's desktop app, your browser, your terminal (as per the requirements of this attack) or perform some other malicious that rapidly terminating CLI session cannot mitigate. 
    
    • In theory immediate session termination does make that one specific thing a bit harder for an attacker, but not by much, and given the baseline level of access this attacker needs, would just cause them to pivot. 
• Let's imagine, though, that we can stop an attacker from exploiting this behaviour, and the attacker is also unable to exploit any other part of your computer system despite their level of access (which is admittedly rather far-fetched).
  • It's likely you, or any given `op` user who chooses to enable this immediate session termination behaviour, may need to revert to more conventional `op` session handling to run a script or some such. In that case, unless you've completely mitigated the compromise, the attacker can now leverage that session behaviour.  
  • But practically speaking the attacker has enough access to your system they don't need to wait for you to disable the immediate session termination feature you describe. 

UX

Even if it's possible to do, mitigating this risk is of limited (but not zero) security value, there's a fairly massive user experience "cost" to implementing it that likely far outweighs the benefit. Especially since the alternative mitigation – not using a machine you suspect is being compromised – is far more effective and comes with no experience degradation. And if you are unaware that your machine is compromised, then you're likely in for a bad time no matter what `op` does. Even if the immediate session termination is an effective, you'd have to never change away from that behaviour while your machine, unbeknownst to you, remains compromised.

• Terminating a session immediately upon a command being executed by the CLI would require the user to authenticate prior to executing each command. That's not a particularly great experience in most situations since in most situations people are executing many commands.
  • In theory this could be a "mode" or some optional setting, but that would introduce some product complexity and end-user complexity and, as described below, provide little meaningful security for the "cost".
• If the CLI behaved this way, it would also go against how all other 1Password clients work: All 1Password clients can be unlocked and remain unlocked unless idle for X period (default is 10 minutes). Having the CLI behave the same way makes the experience predictable. 
  • The threat you describe also applies to 1Password's GUI clients just as much as the CLI.  Since this discussion centres around an auth prompt from 1Password's desktop app integration with `op`, I'm assuming that the desktop application is installed and unlocked. So in a situation where the CLI is being used on a compromised device,  then any malicious actor in a position to obtain values from the CLI is likely to be able to obtain at least some data from the 1Password desktop application as you use it over time. 

At the core of it, you're right: It depends on how the system is compromised. However, the level of compromise required to pull off the attack you are describing is necessarily rather extensive, and would enable an attacker to do much more dire things. 

To that end, given the impacts to the user experience by implementing a mitigation you describe, and the limited effectiveness of that mitigation (or any mitigation that 1Password itself can reasonably implement), I'm not sure this is a threat that 1Password itself can effectively mitigate on it's own. The most effective mitigation with the lowest negative impact to a user's productivity and experience with `op` would be to avoid using a device you suspect is compromised. 

That said, I will pass this thread along to our security engineering team so they can share any additional thoughts they may have (though we cannot guarantee they will necessarily provide any or a detailed response). 

Thanks for sharing your situation and if I have more to share from our internal teams I'll circle back. 

Cheers,
Scott