Using 1Password 's `op` CLI tool exposes your secrets to other users
twitter.com
twitter.com
Of course under Unix and Linux even a single person machine can be running a lot of processes, including nefarious ones…
For example, I remember a thread here on HN a while back about Zoom - which is unfortunately not optional for many people - frequently gobbling up an exhaustive list of running processes. Presumably this is to populate a list of apps you can share the screen off in a call, but we have no guarantees whatsoever that this information stays on the device. So all the user has to do is use that tool at the same time as Zoom looks at all processes and bang, they’ve got your data.
That said: The actual reality where someone gets their password stolen because they used 1Password's ClI tool seems pretty hard to run across. You have to have something running _at the exact moment_ when you're running this tool (and I imagine it shouldn't be running for very long) that also manages to harvest the entire set of running processes and their arguments. Said something then has to also transmit this information to a third-party server AND that third-party server has to be looking for this specific CLI tool in the hopes of catching it running.
Zoom is unlikely to manage to grab a list of processes at the same time that you're using this CLI tool (because it will be doing this on some internal timer or at the time when you are selecting something to share, and you have to be using it while using Zoom which should be a less-frequent occurrence due to generally paying attention to the call). And on top of that, if they even submit this information to their servers, I highly doubt they're going around deliberately scanning for passwords to maliciously use since they're a company focused on teleconferencing and not black hat activities.
And even beyond that this should still be more secure than a common alternative I've run into (and have done myself, because convenience was more important to me than 100% security at those jobs) where developers are just storing passwords and tokens in plain text in a bash/zsh rc file. That's a pretty easy target for a more realistic case of a module on something like NPM gaining some malicious code that checks some common files and patterns (e.g.: a line including export, PASSWORD, and =) and harvests that data to send to a malicious server.
And again, I'm not saying this is _good_, it's definitely not. I'm just saying that the case where this is actually exploited is pretty slim, bordering on not going to actually happen even if something just so happens to harvest that command running and sends it to their servers. Because it's much more likely that the thing harvesting that info isn't interested in stealing your password. There are much easier targets for malicious code to go after.
> I also wanted to respond to a specific part of @ShakataGaNai's original post about the multiple passwords. We've actually been recommending folks use the same password for each of their 1Password accounts. This might sound ironic given that the typical advice w.r.t. passwords is to use a unique password for everything. The difference is that your 1Password account password is intended to be the one password you remember, and so in theory, if you can only dedicate so much brain space to passwords, if you use only one password for all of your 1Password accounts, you'll be able to make that password stronger than if you have to remember multiple account passwords. So part of the new behavior encourages folks that direction.
More context can be found here[2].
[1] https://1password.community/discussion/comment/609753/#Comme...
[2] https://1password.community/discussion/122614/two-accounts-n...
The OP in that thread is complaining that he has to unlock each account separately with its own password. That response is a suggestion to mitigate password fatigue with multiple accounts and restore the same functionality as 1P7.
And as @gmemstr said, each 1Password Account also has a randomized "account key" mixed with your master password, making password stuffing attacks impossible. Your account key is given at signup and manually saved by the user. If you want to add a new device, you need to pull the key from an enrolled device or wherever you wrote it down.
Just got to hope they decided to prioritise the security use case for the things you care about, I guess?
(( hangs head in shame ))