what does the op cli session token grant access to?

slippycheeze

G'day. I'm evaluating if I can safely use the op cli to access secrets on a system that is not fully under my control. The main sticking point is that command line arguments and environment variables are visible to more or less anyone who asks nicely. So, passing the session token on the command line, or as an environment variable, means I need to assume it can be leaked.

Which brings me to my question: what does that token grant access to? I get the impression that it would allow anyone holding the token to download the encrypted vault file, but nothing more. I'd like, of course, to confirm that. Please correct anything I have wrong here about holding the op(1) session token, but no other information:

1. does allow access to the encrypted vault file, presumably in OPVault format
2. does not allow decryption of that vault data
3. does not allow listing account names or other details from the vault
4. is not equivalent to the account secret key
5. is not equivalent to the master password
6. is not equivalent to a TOTP 2-fac token
7. is equivalent to capturing memory of the op(1) caching daemon, if used

Is that all correct? Is there anything I missed to be aware of?

The specific "threat model" here is that the company capture some information about all processes executed, as part of defending against internal and external attackers, especially APT attackers and "zero day" malware. That can include environment variables and command line arguments – so would potentially leak my session token.

What I'm not trying to prevent is the "insider risk" of someone being able to read keyboard input, process output, or process memory holding the decrypted passwords. I simply want to understand what the risk of a leaked session token is, so I can factor that into the overall picture of risk here. :)

note: I gave the platform below, but this is also applicable to the CLI on windows and linux, if I want to run them there, I'd assume. :)

---

1Password Version: op 1.8.0
Extension Version: Not Provided
OS Version: macOS 10.15.7
Sync Type: 1password account

laugher

I'm also interested in this and other risks/concerns I have about the CLI. The whole concept of a CLI having access to our master password database is all very atypical for AgileBits.

When I first heard about CLI, here were my first impressions;

1. One can now potentially more easily script their way to access our master password database
2. One has a new vector to steal or bruteforce their way into our master password database
3. Its been awhile but I was vaguely aware that some CLI shells saves ALL user input. i.e. even what you might type in a child process. This leaves our master password database vulnerable.

I for one hope this is not standard issue with the 1Password for Mac/Windows package. If it is, I would like AgileBits to immediately decouple the 1Password CLI from any of my current GUI installations.

With thanks and lots of concern...

slippycheeze

...here were my first impressions;

FWIW, as I'm not a 1password developer, but security is part of my day job: the architectural docs for 1password CLI, OPVault, and the sync process, make it clear that all your concerns are valid, and have been considered and addressed by AgileBits. If you are comfortable using the 1password GUI then you can be equally comfortable using the 1password CLI.

In more detail, the architecture of the browser extensions, the GUI application, and the CLI (with or without caching) are close enough that your concerns all apply equally to all three of them. That is: it doesn't make it easier to script access to the database via CLI than it was via browser or GUI app.

None of the standard, or even popular non-standard, terminal emulators or shells capture all input by default. If the do, that isn't a 1password problem, that is a "user" problem – in the same way that the fact keylogger software exists isn't a 1password problem, even though they can record the master password being entered in the GUI app or the browser. (that is: if your don't trust the terminal emulator to keep your secrets, don't enter your secrets, because there is nothing any application can do to save you.)

The only thing that might be different about the CLI is that the "session token" – which I believe is equivalent to the browser session cookie for the extension, and which the GUI would also need to maintain to sync the database – is passed as "non-privileged" information. (The environment variables, and command line arguments, of processes are easily accessible to other processes running as the user, and on some platforms, to other unprivileged users. This applies to both GUI and CLI applications, of course.)

I hope that helps reduce any concerns I caused with my question: I thought about the same threats, of course, and read the available design and architecture docs before looking at using it. So, to be extremely clear: your concerns are valid, but the 1password team have addressed them appropriately in designing their system.

laugher

Thanks @slippycheeze

Can you link the architectural docs for the CLI? I'm having trouble finding it.

slippycheeze

....soooo..... turns out that my assumption of "oh, yeah, I don't need to keep track of those" was wrong, and I can't find the document that talked about the design of the op(1) CLI tool cache daemon. https://support.1password.com/opvault-design/ and the linked PDF cover most of the other aspects of the security and vault design.

I am pretty sure I had more of a reference than the manpage of the tool, which documents that "The daemon stores encrypted information in memory using the same encryption methods as on 1Password.com. It can read the information to pass to the command-line tool, but can’t decrypt it. The tool starts the daemon automatically and it terminates itself after 24 hours of inactivity."

Sadly, can't turn that up now, though, so either I imagined it, or I'm not able to find it again. -_-

rickfillion

Hi @slippycheeze,

The session token itself is an encryption key that is unique to your invocation of op signin. This key is used to decrypt the session file that is written to disk. If another user has access to both the session token and the session file then you can assume that they have access to any data you'd have access to and so you should not use op on this system.

Your 1-7 points are all No if and only if the user does not have that session file as well. The token/environment variable is a random key and having access to it alone does not give you anything.

I hope that helps.

Rick

laugher

@slippycheeze I am pretty sure that the arch docs you refer to doesn't exist. There are some docs particularly the man pages you refer to that describe how you go about implementation.

I think you might have assumed that the security context for the other 1Password GUI components applied to the CLI.

I would caution using this in a production environment until more light is shed by AgileBits in this area. I suspect the corporate wording will result in comms to the effect of, "...the shell forms part of the OS environment and 1Password cannot be expected to manage threats in that space. Just as 1Password cannot be expected to manage the threats of keyloggers, malware, etc in their GUI client."

If you ever find the architecture docs, please do let me know. :)

laugher

Went through and tried to find op binaries and couldn't find them in Mac OS and Windows. Sighing with relief.

slippycheeze

@rickfillion thank you for the explanation. That is what I wanted exactly, and I appreciate the info. It lets me edecide if the risk of someone holding both is worth the benefits. (No, in this case, for me.)

@laugher is right, too, that I imagined the design doc for the CLI, I think. (wretched brains, not helpful.)

It'd be great if y'all considered one, similar to the vault white paper. I guess for the non-cli apps too.

Just the threat models, what secrets are succeed where, use of secure memory, mlock, etc. Not the same "implement your own" of the vault.

Either way, thanks!

ag_yaron

Thanks for the suggestion @slippycheeze .
We'll look into improving our docs of the CLI and its ins and outs :)