Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

1Password CLI Vulnerability

codeberg.org

Post reply on HN
Print view View original

51–60 of 67 posts

Re: 1Password CLI Vulnerability

#51

Post by halfcat »

conception wrote: post #36
troad wrote: post #33

I really wish I could restrict CLI access to 1Password per vault (or even per item). When I briefly tried Kamal, it made me very uncomfortable for a script to ask for access to my entire 1Password - every login, credit card, etc. While I do not think Kamal is malicious, in the context of all the constant supply chain attacks, saying yes to anything like that seems extremely irresponsible. This seems like an area wher…

Use a service account via cli?

A service account sounds like one step forward, two steps back.

It can limit the scope of accessible vaults, which can help but only if you do the legwork of keeping multiple copies of secrets in separate vaults and managing service account tokens.

But the token is just in an environment variable, which if we’re worried about this supply chain malicious library scenario, is no different than keeping your secrets in a plain text .env file.

And worse, a service account doesn’t prompt the user.

The functionality of `op run —env-file .env — some_app` which then prompts the developer is what we’d want in a dev environment, just with finer grained permissions and options to prompt every time.

But realistically, if someone can execute code on your computer, they can get to your entire 1Password account through scraping the app, key logging, sending keystrokes and screenshotting, etc.

Re: 1Password CLI Vulnerability

#52

Post by halfcat »

e40 wrote: post #44
troad wrote: post #33

I really wish I could restrict CLI access to 1Password per vault (or even per item). When I briefly tried Kamal, it made me very uncomfortable for a script to ask for access to my entire 1Password - every login, credit card, etc. While I do not think Kamal is malicious, in the context of all the constant supply chain attacks, saying yes to anything like that seems extremely irresponsible. This seems like an area wher…

This is the takeaway from this disclosure. Everyone using op should create a service account and expose only the secrets that need access via the CLI. That greatly decreases the attack surface.

And makes it invisible if you’re compromised in a supply chain attack.

The flip side would be, you install your dependencies, and one tries to run `op …` and you get a 1Password popup on your screen, which should surprise you because you didn’t run `op` yet. Supply chain attack mitigated (maybe).

With a service account there is no prompt and your secrets, though now more limited in scope, and exfiltrated successfully and silently.

Service accounts are definitely not the silver bullet. 1Password should just add more fine-grained permissions and prompting options to get closer to an ideal solution.

Re: 1Password CLI Vulnerability

#53

Post by e40 »

halfcat wrote: post #52
e40 wrote: post #44

Earlier quoted context omitted.

This is the takeaway from this disclosure. Everyone using op should create a service account and expose only the secrets that need access via the CLI. That greatly decreases the attack surface.

And makes it invisible if you’re compromised in a supply chain attack. The flip side would be, you install your dependencies, and one tries to run `op …` and you get a 1Password popup on your screen, which should surprise you because you didn’t run `op` yet. Supply chain attack mitigated (maybe). With a service account there is no prompt and your secrets, though now more limited in scope, and exfiltrated successfully…

I agree with this. It would be nice if there was an option, per item in 1PW, that allowed a popup for access via the service account.

Re: 1Password CLI Vulnerability

#54

Post by zen928 »

macintux wrote: post #28
crazygringo wrote: post #27

Earlier quoted context omitted.

So again, how does an Electron bug become 1Password's fault? It's cross-platform and integrates with browsers so it makes sense they would want to use a cross-platform JavaScript solution as much as possible. Not just to make their developers more efficient, but to reduce the surface area for bugs and vulnerabilities.

1Password used to be an excellent native app. It's not surprising that many users (myself included) resent the enshittification.

You personally disliking something isnt enshittification.

Re: 1Password CLI Vulnerability

#55

Post by InitialBP »

starburst wrote: post #31

I’m surprised the CLI doesn’t asked permission for each program trying to access it, when using their SSH agent I get a popup for any program (then it unlock that key for that program until session ends). People dismissing this vulnerability miss the point of a password manager which is to protect in such scenario where code gets executed on a machine but at least the data is encrypted, of course in that scenario the…

I believe the CLI _does_ ask permission for each program trying to access it. The author's example includes a malicious vscode extension abusing the fact that he intentionally granted vscode permission to access the vault for one purpose and then a malicious extension leveraged that access to retrieve information through the op cli.

Re: 1Password CLI Vulnerability

#56

Post by macintux »

zen928 wrote: post #54
macintux wrote: post #28

Earlier quoted context omitted.

1Password used to be an excellent native app. It's not surprising that many users (myself included) resent the enshittification.

You personally disliking something isnt enshittification.

It was done at roughly the same time that the company switched to a subscription model and their focus switched from consumer to business.

Re: 1Password CLI Vulnerability

#57

Post by jen729w »

lexicality wrote: post #47
jen729w wrote: post #13

Earlier quoted context omitted.

Oh wow, my bad. I saw 2024 as the disclosure and thought, well obviously 1Password have fixed that by now . Huh. Unflagged. So, as someone who literally last month moved all of his .env in to 1Password and was feeling pretty, pretty smart about it: what now? (Did that, by the way, on the advice of a comment here in response to the previous npm hack, whatever that was, where that commenter said 'you're a fool if you d…

> what now? Put the secrets in their own vault, use a service account to access them and then follow the same rules as sudo's grace period - dedicated terminal session, run only the commands that need to be privileged and exit the session as soon as you don't need it any more

I’m a solo dev. Service accounts are an enterprise feature.

Re: 1Password CLI Vulnerability

#58

Post by tredre3 »

woadwarrior01 wrote: post #17

1Password used to be good 10 years ago, but not anymore. A couple of days ago, there was a post about Electron based apps that slow down macOS Tahoe (due to older versions of Electron using an undocumented API). When I ran the script on my laptop, 1Password was on the top of the list. > 1Password.app: Electron 37.3.1 (Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework) [1]: https://news.yc…

I guess you're being downvoted because you've just now realized that 1password is electron-based and you're using that discovery it to retro-actively confirm your pre-existing bias that electron = bad.

If electron was actually always bad, you wouldn't need a script to scan your machine and tell you which apps to hate, you'd just know "yep that's slop" upon first opening the app. Yet that is not the case. Because electron is a tool, and it's sometimes used so well that you don't even notice it until you run a script.

Re: 1Password CLI Vulnerability

#59

Post by jen729w »

macintux wrote: post #56
zen928 wrote: post #54

Earlier quoted context omitted.

You personally disliking something isnt enshittification.

It was done at roughly the same time that the company switched to a subscription model and their focus switched from consumer to business.

...shortly thereafter, Apple released their own Passwords app, largely Sherlocking 1Password from a consumer perspective.

If this had been your business, what would you have done? I would have done exactly what they did.

Re: 1Password CLI Vulnerability

#60

Post by jen729w »

jen729w wrote: post #57
lexicality wrote: post #47

Earlier quoted context omitted.

> what now? Put the secrets in their own vault, use a service account to access them and then follow the same rules as sudo's grace period - dedicated terminal session, run only the commands that need to be privileged and exit the session as soon as you don't need it any more

I’m a solo dev. Service accounts are an enterprise feature.

I'm wrong again! See the rest of this thread.
Post reply on HN