Where is the vault decrypted when using the op CLI tool?

CamJN

I know the secret key is saved in the ~/.op/config file, after the first login, however I'm having trouble working out how the master password would be applied client side in the decryption process for subsequent commands since the op tool doesn't seem to keep an agent running. Is the vault decrypted server side? If so why isn't this more prominently mentioned, and if not how are you using the master password to derive the decryption key in subsequent runs?

---

1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided

cohix

@CamJN Great question! We are indeed doing all cryptographic operations client-side (we never, in fact are able to decrypt your data server-side, since we don't have your keys).

When you run op signin, we generate a file that includes your MUK (Master Unlock Key), and your session key (specific to each sign-in), and we generate a random key to encrypt that file. We save the file to disk, and the encryption key is output from op signin. The encryption key (which we call the session token) is generally saved to an env var using eval $(op signin), so that on subsequent runs of the CLI, it can fetch that token, decrypt the file on disk, access your session key and MUK to do all its local operations. The encrypted session file is saved in $TMPDIR (wherever that is on your particular system), and is deleted when your session expires the next time you run op signin.

I hope that helps! Let me know if you have any questions.

CamJN

Awesome, that's a great answer! Thanks.

cohix

You're welcome!

c__

@cohix Sorry to take this thread on a bit of a tangent, but I have some follow-up questions related to the response I read on this thread.

Do I understand correctly that the only thing enforcing the CLI session timeout mechanism is the subsequent invocation of the op client program? If that's the case, I don't understand what security property the timeout mechanism is supposed to add.

If an attacker manages to grab a copy of the encrypted session file at any time before subsequent op signin (which would delete the file), as well as the relevant session token (at any time), they could decode the encrypted session file and acquire the MUK. It's possible the session file persists indefinitely since we never know the user will run op again and $TMPDIR is not guaranteed to be wiped.

A simple "agent" could run in the background and at least remove the encrypted session file at timeout (that doesn't require a lot of sophistication or IPC); heck, a more sophisticated agent could just remove the need for the on-disk file entirely. Either seems sufficient to fix the gap where timeout occurs before an attacker has the ability to copy the encrypted session file.

But maybe I'm getting ahead of myself and the signin time is somehow incorporated into the temporary key material in a way that makes session file decryption impossible after timeout without relying on subsequent op signin invocation?

Thanks for entertaining my questions!

cohix

@c__ ,

You are correct that if someone was able to obtain the encrypted session file and the session token, they could then decrypt the MUK.

The timeout is enforced server-side, so no interaction with the server is possible once the timeout has expired.

c__

Hi @cohix ,

Thanks for the information.

Is it not problematic that an attacker could derive the MUK after the timeout? If my understanding of the 1password design whitepaper is correct, the MUK can decrypt the user's Private Key and therefore Vault Keys, and is never invalidated until the Master Password is changed. That outcome seems somewhat bad even if the attacker cannot communicate with the 1password server.

Granted, an attacker who can steal from local /tmp and somehow steal the Session Token already has quite a bit of access, and if they're in the user's account they can probably hijack the browser with ptrace and sniff the Master Password in plaintext anyway. So this scenario feels pretty contrived.

On the other hand, if we are not concerned because the server token timeout is enforced on the server side, why do we delete the file after timeout at all?

cohix

@C__,

There is only so much that can be done in the scenario where an attacker has full access to a user's machine. We do our best to protect against this, but if your machine is that far gone, then the best we can do is invalidate the session so that the attacker cannot download any of your data. The MUK and session key are not enough to create a new session, so the attacker would only have the key, not the data that the key has encrypted.

We delete the old files simply to clean up, no real other reason!

c__

There is only so much that can be done in the scenario where an attacker has full access to a user's machine.

Indeed!

We delete the old files simply to clean up, no real other reason!

Ok, thanks for the insight!

AGAlumB

:) :+1: