Sidenote, but nice to see a few more Codeberg links popping up instead of the ubiquitous GitHub. Maybe we’re decentralising a little more in this area.
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)
Edit: Judging by the downvotes, it looks like there are a lot of electron lovers here. Why the hate for more efficient native apps? Are bloated binaries, janky UI and lower battery life, features? :)
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.
If someone has arbitrary code execution on your machine as your user, then of course they can access things your user can access.
They could just as easily keylog your password, or replace the onepassword-cli binary with one that exfiltrates data, or steal your browser cookie to get into your email account and use that to hijack recovery flows...
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 attacker can get access to the plain text env variables anyway that the developers has on their machine but at least it is not ALL of your credentials like in this case.
Service Account can limit the blast radius BUT you’ll end up saving that API token in your env anyway giving access to anyone executing malicious code…
Using their CLI is dangerous if they haven’t done anything to protect in this scenario. Did they have any comments in that vulnerability and how they want to mitigate it?
Why not simply return the value of the requested items and that’s it? Why unlock everything in a CLI scenario, surely the most common case is simply grabbing a single item like a .env for a project and that’s it.
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 where there'd be obvious value in applying the principle of least privilege, so I was surprised when I couldn't find any granularity to the CLI permissions in 1Password.
CLI tools have weaker security models than their GUI counterparts bc the assumption is usually that if you have terminal access, you already have elevated privileges.
But in shared environments or CI/CD pipelines, this doesn’t work. And the credential exposure through process lists is pretty bad.
When I execute code on your machine, you are lost. Simply like that.
Don't store important passwords on your machine in a single point of failure. It's safer to store them unencrypted in a wrong named textfile than on the place where everyone will look automacially at first.
But more secury is it to NOT store them at all on your machine.
To limit the attack surface here, maybe follow the permissions model on macOS, access a credential = TouchID/Password each time, just limiting dependencies, still leaves a large attack surface of accessing everything if an attacker is able to find a route through, that’s what they’re looking for is everything right there, somehow some way.
18 comments
[ 6.3 ms ] story [ 49.5 ms ] threadI’m confused why this is just be publicly disclosed. It’s been known for 2 years!
> 1Password.app: Electron 37.3.1 (Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework)
[1]: https://news.ycombinator.com/item?id=45437112
Edit: Judging by the downvotes, it looks like there are a lot of electron lovers here. Why the hate for more efficient native apps? Are bloated binaries, janky UI and lower battery life, features? :)
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.
If someone has arbitrary code execution on your machine as your user, then of course they can access things your user can access.
They could just as easily keylog your password, or replace the onepassword-cli binary with one that exfiltrates data, or steal your browser cookie to get into your email account and use that to hijack recovery flows...
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 attacker can get access to the plain text env variables anyway that the developers has on their machine but at least it is not ALL of your credentials like in this case.
Service Account can limit the blast radius BUT you’ll end up saving that API token in your env anyway giving access to anyone executing malicious code…
Using their CLI is dangerous if they haven’t done anything to protect in this scenario. Did they have any comments in that vulnerability and how they want to mitigate it?
Why not simply return the value of the requested items and that’s it? Why unlock everything in a CLI scenario, surely the most common case is simply grabbing a single item like a .env for a project and that’s it.
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 where there'd be obvious value in applying the principle of least privilege, so I was surprised when I couldn't find any granularity to the CLI permissions in 1Password.
But in shared environments or CI/CD pipelines, this doesn’t work. And the credential exposure through process lists is pretty bad.
Don't store important passwords on your machine in a single point of failure. It's safer to store them unencrypted in a wrong named textfile than on the place where everyone will look automacially at first. But more secury is it to NOT store them at all on your machine.