Consequences of secret key stored in plain text in ~/.op/config?

VirtualWolf

I've been mucking around with the new CLI and it's pretty nice! I have some files sitting in my home folder that contain access tokens and the like that I set environment variables with to use in some Node.js applications I write, and was intrigued by the idea of replacing them with a dynamic call to op so the tokens don't have to be sitting on there in plain text. So instead of export API_KEY=<key> I could do an eval $(op signin <address>) at the top of the script then do export API_KEY=$(op get item '<item name>' --fields 'api key') and as soon as the terminal session is closed, that environment variable is gone. I made that change and it works a treat, except I see the secret key now lives in ~/.op/config` in plain text, which feels to me less appealing than having the individual API keys sitting that way, heh.

I see in the 1Password white paper that under macOS the secret key is stored in the macOS keychain, would it make sense to do that with the CLI as well? Or am I entirely misunderstanding the threat model for this and it's not really a concern at all? 😅 (I'm not any sort of security person, just someone with a vague interest).

Cheers!

---

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

tasdf

I'd be interested to hearing the answer to this as well. I know, ssh keys are stored in ~/.ssh, etc., but...

VirtualWolf

Aye, that thought had occurred to me as well, but they're (ideally) password-protected.

Though I guess by the same logic, the secret key isn't any use unless you also have the master password...

Ben

Hi folks,

I'm sorry for the delayed reply here. I'd be happy to help with that.

the secret key isn't any use unless you also have the master password...

This is a big part of it. Another big part is that the Secret Key isn't intended to be secret within your system. The purpose of the Master Password is to protect your data that is on your computer. The purpose of the Secret Key is to protect the data that is on our servers.

About your Secret Key

Ben

VirtualWolf

Ahh, makes sense, I missed that distinction! Cheers Ben. :)

I guess by the same token I should ensure that I don't have Time Machine or Backblaze backing up the ~/.op directory either. (My backups to Backblaze are encrypted with my own passphrase anyway, but still).

Ben

If you are encrypting your backups it may not be necessary to exclude the files from those backups, but that's certainly something you may want to consider based on your use case.

Ben

tasdf

That does make sense and is the type of thing I might have overlooked. Can I ask if the regular macOS app stores the secret key somewhere 'available' that can accidentally get propagated unintentionally via a backup?

Ben

Yes - it does, as does your web browser if you use it to log into the web app. From our Security Design White Paper:

Locally exposed Secret Keys
Once a client is enrolled, it will store a copy of the Secret Key on the local device. Because the Secret Key must be used to derive the user’s MUK it cannot be encrypted by the same MUK. Although lightly obfuscated, the Secret Key is stored on the local device unencrypted. Where possible, the Secret Key will be put into something provided by your system for storing authentication secrets. For 1Password for Mac and 1Password for iOS that will use the iOS and OS X keychains respectively. But when 1Password has been used from a web browser, the Secret Key is stored in the browser’s local data store, a fairly exposed location.
Recall that the Secret Key is designed so that an attacker will not be in a position to launch an offline password guessing attack if she captures data from the server alone. It does succeed at that goal, but in the current version, our ability to protect the Secret Key on your computer is limited by the tools available to that particular client.

Ben

tasdf

Ahh, okay. So at least the app's secret key on macOS is nominally encrypted in a backup, as it lives in the system keychain. That is good to know. I will make sure to exclude the CLI secret key from backups.

I guess there wasn't a way for the CLI program to read the secret key from the system keychain?

Ben

Ahh, okay. So at least the app's secret key on macOS is nominally encrypted in a backup, as it lives in the system keychain. That is good to know. I will make sure to exclude the CLI secret key from backups.

:+1:

I guess there wasn't a way for the CLI program to read the secret key from the system keychain?

Not currently, though that may be a choice we can reconsider in the future. :)

Ben

phatmandrake

I had the same question. It would be helpful if this kind of explanation was perhaps made available in the CLI documentation.

Although I would like to know why the secret key is stored in the keychain if it's also is intended to be exposed in a config file. It's clear it's not the biggest issue so I'm not worried just more curious than anything. It seems contradictory in my mind, at least to my level of understanding.

cohix

@phatmandrake Absolutely, we are looking at ways to improve the documentation and that's a great suggestion.

The CLI is meant to be as platform-agnostic as possible and we have thus far avoided adding platform-specific features (such as using keychains) for ease of testing. That may change in the future, but for now we keep it simple :)