Token Management

skunkwerks

After a few months of usage, some suggestions around tokens and approval:

1. Check for Token

The main thing here is that seeing a unix process list shouldn't show the session token in the args list. Basically I'd like op to behave like hashicorp's vault when looking for the session token:

• use the token provided on the command line
• check for an environment variable ${1PASSWORD_TOKEN} then use that
• check on disk if it's stored in ~/.1password/token then use that as a last resort

I don't personally approve of the last option but I can imagine many circumstances where this will be useful, especially when combined with the following ideas.

2. Token Restrictions on Lifetime & Usage

It would be very handy to have tokens expire not just after a certain period of time has passed, but also after N uses -- you can pass the token to a script and know that after it has retrieved e.g. an ssh key, the token is now useless.

I'd like to have scopes for a token - this time-limited and use-limited token is valid only for a particular secret or secrets, and ideally would trigger an email or some other alert if the token were to be used against other secrets.

3. Active Approval

Duo security have a sweet app for iphone/android that requires you to actively approve a Thing. It would be superb to have this built into 1password so that a script runs, and then waits for op to confirm that the iphone app has Approved All The Things befor spitting out the requested password or secrets.

I know these might be out of scope for 1P at present but these are the things where I use hashicorp vault instead of 1P.

---

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

rickfillion

Hi @skunkwerks,

Thanks for the feedback. Much appreciated.

Check for Token

I'm going to file an issue so that we can look at doing this better. Technically someone would need both the session key + the saved session data that lives in ~/.op/ which should only be available to current user, but it'd be nice if the session key was more hidden.

Token Restrictions on Lifetime & Usage

Ohhhh... I like that! I'd want this controlled by the server so that it can't easily be bypassed/reset. Love love love this idea. :)

Active Approval

This is interesting too. We use Duo for MFA with 1Password Teams and it's pretty neat. I wonder if technically this needs to be a part of the CLI tool at all. We could probably build this all server side such that certain calls require approval, then any client that did those calls would have their request either block until timeout or approval happens. Or the request can go into a queue to be approved later so that it doesn't need to be blocking for the client that performed the task but the server won't act on it until approved.

I was going to say "keep the feedback coming!" but then I remembered that you've got another thread started that I suspect is just that.

Rick

svondutch

It would be very handy to have tokens expire not just after a certain period of time has passed, but also after N uses -- you can pass the token to a script and know that after it has retrieved e.g. an ssh key, the token is now useless.

In addition to what @rickfillion said above, I would like to draw your attention to the op logout command. If you pass a session token to that, then this will end the session and invalidate the session token.

dcreemer

+1 to @skunkwerks proposal for environment variable support.

rickfillion

Thanks @dcreemer.

Rick

skunkwerks

@rickfillion <3 the idea of a token that requires active approval to proceed. There are lots of areas we'd be able to use this as I think everybody has the 1P android or iOS app installed already, although I use duo personally.

@svondutch so this would still require a user (e.g. me) to have logged in with op login <acme_corp> first, and then run the job manually? If the job needs to run at 2am do you see a way to make that work?

svondutch

+1 to @skunkwerks proposal for environment variable support

@dcreemer While environment variables are volatile/disposable (eg. not saved on disk), you are essentially making your session key available in the clear. Assuming an admin can check the environment of a running process, I worry about the security implications of storing your session key in an environment variable. I would love to be proven wrong though.

so this would still require a user (e.g. me) to have logged in with op login first, and then run the job manually? If the job needs to run at 2am do you see a way to make that work?

@skunkwerks If the op CLI does not touch your session, then it will expire automatically after 30 minutes. I expect this to be well before your job runs at 2am. That being said, I believe your suggestion of expiring a session token after N uses is an excellent idea.

dcreemer

Probably better for me to describe my use cases and let you sort out a solution (if possible). I have many scripts that rely on keys in my password vault. I run these on my desktops interactively -- they do things that generally need to interact with remote systems.

Currently those keys are stored in files encrypted with GPG, and my gpg-agent is configured to cache my master key for 24 hours.
Once a day, as I run some script, I will be prompted for my GPG password. This is similar to 1Password desktop's "Lock after computer is idle for n Minutes" setting.

So the question is, how can I avoid keeping my keys both in a GPG encrypted files, and my 1Password vault?

dcreemer

In this thread -- https://discussions.agilebits.com/discussion/80027/provide-master-password-via-stdin -- I learned I can provide my master password via stdin. This solves my problem! I can store my master password in GPG encrypted file, and script the rest.

rickfillion

That's a neat way of solving that.