It’s Cybersecurity Awareness Month! Join our interactive training session, or learn about security and AI from 1Password experts.
Forum Discussion
Solved
Security concern with allowing Terminal complete access to my 1P account via op CLI
I have a shell script that uses 1Password secret reference:
export EXAMPLE_API_KEY=$(op read "op://Vault-Name/Example API Token/Specific-Token/Token")
But when it's loaded, I have to au...
Hi Integralist,
This is a great question. I think this falls into the same category as risks associated with malware or similarly compromised devices: there's very little any application can do to prevent that entity from accessing any information on your computer that the authorized user can access. An attacker that has the same permissions you have on the device (as is true in the scenario you are referring to in which there is arbitrary malicious code being executed) can at least theoretically access anything you access.
The CLI behaviour you outline doesn't meaningfully increase the risk in a situation like this because such an attacker with the level of access you describe doesn't require the CLI to behave this way to do harm, including potentially learning something about your 1Password data, since 1Password is necessarily unlocked in your scenario.
It sounds trite, but the answer almost always is: It's never safe to run any application on a device that is, or suspected to be, compromised. If you suspect your device is compromised, you should not unlock 1Password. That should at least prevent the attacker from obtaining any 1Password data (as for all the other data on your computer... that's a different story).
We do our best to protect your data even in the event of a compromised device, which you can read a bit more about here: https://blog.1password.com/local-threats-device-protections/
But at the end of the day, there's not a lot that any application can do to completely eliminate this risk. 1Password in it's locked state, however, would be almost an impossible nut to crack.
This might be slightly tangential to the original point here but I find it confusing that using `op read` for a specific secret reference results in a permission prompt for "allow[ing] terminal session to get full
access to your account". I would 1) like the permission prompt to show what specific vault item is being accessed/requested, and 2) why does the permission access last the rest of the terminal session? 2) should default to unlocking for just the single invocation in my opinion, or at least be configurable with a toggle/checkbox on the initial permission prompt.
I think you are describing the same problem as I did 4 months ago. I was building automation scripts that need to fetch some specific secrets. In my case I know what the scripts do, but not all of the team does, which lead to hesitation and confusion, when the op command shows up as a generic "do you want to open up the vault for anything" for the end-user. In my case other developers on the team.
The problem is that 1Password cli does not support passing a list of secrets to be read, which requires developing a new use-case flow. They have not decided to do that yet, but I'm happy that I'm not alone to ask for it.
