Mac Touch Bar Finger Print access to CLI signin

bbakerman

I would like to be able to use the TouchBar Finger Print in the CLI as I can in the UI. (on Mac)

Ideally eval $(op signin myaccount) would invoke the TouchBar FingerPrint and this would then signin.

I guess it would have the same timeout rules as the UI and ask me for passwords in the same manner as the UI does.

I am using the CLI multiple times an hour and typing in the password is driving me crazy.

if its secure enough on the UI why not on the CLI?

---

1Password Version: 7.6
Extension Version: Not Provided
OS Version: Mac 10.15.6
Sync Type: Not Provided

felix_1p

Do you know any other command line tools that use TouchID? I'm asking because I haven't found any information for how this would work.

We need the master password one way or the other, otherwise we cannot derive the necessary secrets to authenticate you and decrypt your data.

If you want to streamline password entry, you could store your Master Password in Keychain and access it from the command line with the security command:

eval $(security find-generic-password ... | op signin myaccount)

I'm not sure how security verifies access though.

k3cua8

I'm a recent convert from LastPass (including the cli) and I'm mostly happy with the switch to 1password. However, the 1password-cli timeout is my quickly becoming my biggest pain point (see related reddit discussion here).

Using Keychain is an interesting idea but would obviously only work for macOS users. I can look into using it, but it does feel a little hacky.

I would love it if there was a mechanism to either increase the cli's timeout/idle-timeout or have more control over it. Other similar tools have variables that help with this: (LastPass-cli has LPASS_AGENT_TIMEOUT, Saml2Aws has SAML2AWS_SESSION_DURATION, aws-vault has --duration, awscli has AWS_FEDERATION_TOKEN_TTL, AWS_ASSUME_ROLE_TTL, and relatedly AWS_SESSION_EXPIRATION, etc.

I think it would be great if 1password-cli had that kind of a setting to bring it up to par with those tools with similar use cases.

k3cua8

Forgot to mention that aws-okta has --session-ttl

bbakerman

eval $(security find-generic-password ... | op signin myaccount)

I investigated the Mac KeyChain and the security CLI tool. The challenge with it is that once again you have to enter your master password every time OR you trust the security tool in the CLI and it never asks for a password because that program is trusted - which defeats the attack vector of someone coming into my terminal and running the command to get the master password

I guess I am asking for an option on the CLI (on mac) to accept the finger print or give me the passsord (which I know is hybrid of CLI and UI)

Today if I click the OnePassword UI and I have not logged in for a while the TouchBar is an option (once set up). I am after that

op signin myaccount --fingerprintprompt is kinda how it might look

felix_1p

@k3cua8 I think the timeout is provided by the sever, but I will double check on that. On my machine (Linux) I'm storing my Master Password in a GPG encrypted file. The GPG key is stored on a YubiKey. When I execute the wrapper script around the command line tool I'm asked for a pin only, which makes things easier.

@bbakerman I was informed that Touch ID access is not supported for command line tools. Apparently there is no way to "authorize" command line tools in such a way that they would be allowed to access that API.

k3cua8

Hi @felix_1p , thanks for the response. Alternatively, if I look at the Security Settings of my "1password X" chrome extension, there is a setting called "Lock after system is idle for" and it gives the option to set this between 1 and 999 minutes. That definitely sounds like something that would resolve this issue. Is there an equivalent setting of this in 1password-cli? If not, it would be great if it could have one.

felix_1p

@k3cua8

Is there an equivalent setting of this in 1password-cli? If not, it would be great if it could have one.

There is not. The biggest difference between the command line tool and all the other clients is that the command line tool is not a long running process. Other clients have the ability to transparently create a new session or to keep the existing alive, by making requests to the server.

At least for the time being, establishing a new session with the command line tool requires the Master Password. And since we obviously don't store that anywhere, we cannot transparently create a new session.

Depending on your setup you might be able to periodically issue "dummy requests" to the server (e.g. op get account) to extend the current session beyond its 30 minute timeout (the timeout is always measured from the moment of the last communication with the server).

k3cua8

I tried emulating this workaround, somewhat. But I found that new terminal sessions always asked for signin. So what I did different was I tried saving my op session token to a file so that new terminal sessions could read from it. That part works, but none last more than the 30 minute timeout for some reason.

# create private hidden file to store op session token
$ (umask 077 touch ~/.token)
# after logging in successfully to op, save the session token to that file
$ eval $(op signin my) && echo ${OP_SESSION_my} > ~/.token

# run script every 20 minutes during work day to reset op session timeout, reading the session token from the file
# otherwise, new terminal sessions always ask for signin
$ crontab -l
0,20,40 7-17 * * MON-FRI ~/.pm_token_refresh.sh
$ cat ~/.pm_token_refresh.sh
#!/usr/bin/env bash
/usr/local/bin/op get item my-item --fields username --session $(cat ${HOME}/.token)
$ chmod -c u+x ~/.pm_token_refresh.sh

k3cua8

I just saw 1.6.0 is out with a related improvement so will try that out as soon as brew cask sees it.

k3cua8

Nice. 1.6.0 did, in fact, make it so you can pass in an existing and active session token so that "op signin my --session ${OP_SESSION_my}" won't prompt you for your password.

However, it still seems my cronjob that runs an op command every 20 minutes fails to keep that session token active. Any other ideas? Can anyone else reproduce this problem?

felix_1p

However, it still seems my cronjob that runs an op command every 20 minutes fails to keep that session token active.

Hmmh. Does the session get extended when you run the script manually? I don't see a reason why it shouldn't get extended.

k3cua8

Good idea, I'll try that

k3cua8

Yes that works. So something with the cronjob isn't working. I'll have to rework it to assume a fuller session.

ag_yaron

Hey @k3cua8 ,
Did you manage to get that cronjob to work? Are you able to keep the session alive automatically now?

k3cua8

Hi @ag_yaron, I couldn't get it to work via cronjob. I played around with importing my environment variables into the cron job but no luck. I could only get it to work with a manual for loop. So I'm not sure if there is some kind of tty requirement.

Anwyay, now I'm playing around with backgrounding/nohup'ing/disowning the for loop - but still no luck with that yet (see below).

I would be really nice if there was a native mechanism with the 1password-cli to extend the session timeout. Otherwise the burden is on each user who needs something like it to come up with workarounds like this.

nohup sh -c 'for i in {1..21} ; do \
  op signin my --session ${OP_SESSION_my} \
  i++; sleep 1740; done' &

        (
          {
            nohup sh -c 'for i in {1..21} ; do \
              op signin my --session ${OP_SESSION_my} \
              i++; sleep 1740; done' > /var/tmp/output.txt
          } & disown
        ) 2> /dev/null

ag_yaron

I'll definitely file this as a feature request. Thanks for the feedback and info @k3cua8 !

c4sKzkJRzVai

This is not exactly a way "to authorize command line tools in such a way that they would be allowed to access [the TouchID] API," but you can enable TouchID for sudo: https://sixcolors.com/post/2020/11/quick-tip-enable-touch-id-for-sudo/ - perhaps there's a way to use this?

rickfillion

Sadly what's done for sudo would not work for 1Password.

A while ago I was actually working on this on a lazy sunday afternoon. Writing code to ask the user for Touch ID from the command line is quite trivial. That part I had up and running within an hour or so. The hard part is that Touch ID itself doesn't protect anything. It's an authentication mechanism, all it can tell an app is whether Touch ID itself was successful. 1Password doesn't just need authentication. 1Password ultimately needs your Master Password (or some equivalent-type secret) in order to derive the keys needed to decrypt your data. The challenge in a CLI app is where to store that secret securely. The Mac has this awesome Secure Enclave that can be used for this problem (and that's what we use in 1Password for Mac), but a CLI tool can't have the entitlement required to access the Secure Enclave unless the CLI app is within an app bundle that has been granted that entitlement.

So basically to make this work we would need to fundamentally change how the CLI tool gets distributed on the Mac. We've not written this off completely but it's not very appealing. We've filed a feature request with Apple to allow the entitlement to be granted to a standalone binary like ours, and maybe one day they'll make that possible.

Rick