Protect what matters – even after you're gone. Make a plan for your digital legacy today.
Forum Discussion
Solved
1Password CLI vulnerability?
I saw this vulnerability disclosure on hackernews and the basic gist of it seems to be that if you have malicious software running on your computer and you give the credentials to your 1password account to that malicious software, it will be able to extricate all your secrets. Which is known.
I think he makes a fair point about 1password-cli currently being too much "all or nothing" unless you use service accounts and I think the first three proposed fixes would be a welcome usability addition, but they would only make it harder to extricate secrets, not impossible. The last one "Prompt for each process individually, closing the gap for subprocesses" seems impractical, throwing up too many access prompts for unknown sub process names, which would quickly become a "Just click allow" situation.
I'd appreciate it if someone from 1password would comment on his report.
This thread was discussed further in the 1Password Developer Slack, but also wanted to share the response here for visibility:
These are great points you're making, and more fine scoped local access has been on our radar for a while. Some background: on the CLI side, we started out with an authorization model that would enable every use case right off the bat. Managing vaults, creating service accounts, provisioning users, etc. The drawback of that approach is that if you just want to load a few secrets for local development, you'd authorize more than needed. Now, because of its power, we've made it so that you're only authorizing the current shell / parent process with a timeout of 10 minutes of inactivity. This adds a layer of protection in the malicious IDE extension case, for example.
For the "read secrets for local dev" use case specifically, we recently announced a built-in .env integration, which does scope local read access down to only a specific set of pre-defined secrets. Besides addressing the access scope point, it'll also give you offline support and a new UI to manage and collaborate on secrets in a given environment.
That said, we do certainly still see value in bringing more fine-grained local authorization to the CLI / SDK side in the future.
2 Replies
- 1P_Vithyea
1Password Team
This thread was discussed further in the 1Password Developer Slack, but also wanted to share the response here for visibility:
These are great points you're making, and more fine scoped local access has been on our radar for a while. Some background: on the CLI side, we started out with an authorization model that would enable every use case right off the bat. Managing vaults, creating service accounts, provisioning users, etc. The drawback of that approach is that if you just want to load a few secrets for local development, you'd authorize more than needed. Now, because of its power, we've made it so that you're only authorizing the current shell / parent process with a timeout of 10 minutes of inactivity. This adds a layer of protection in the malicious IDE extension case, for example.
For the "read secrets for local dev" use case specifically, we recently announced a built-in .env integration, which does scope local read access down to only a specific set of pre-defined secrets. Besides addressing the access scope point, it'll also give you offline support and a new UI to manage and collaborate on secrets in a given environment.
That said, we do certainly still see value in bringing more fine-grained local authorization to the CLI / SDK side in the future. The developer experience of using the local app auth for local dev, and service accounts for prod environments is extremely appealing. However given the recent onslaught of supply chain attacks, this is becoming much more important - both thinking through how to stop it completely, and how to limit blast radius.
I would also add that the same issues need to be considered for any SDK + local app integration (cc 1P_Vithyea )
Both of the suggestions provided (progressive unlocking and limiting programatic access per vault/item) would be a huge win. I can also imagine some kind of token based features, where the access to an item/vault is also tied to an additional token that must be passed in with the programmatic request, whether by CLI or SDK.
