Alternative to passing secret-key on the command-line

ELLIOTTCABLE

There's some slight discussion of this in another thread; but I'd like to bring it up in its own one:

I'm really uncomfortable with pasting my secret-key at the command-line! On the one hand, I want to assume that y'all know more about Security Stuff than I do, but on the other, this is … pretty janky. That means it's:

• Stored to my .zsh_history (and shows up if I type op and then too many ↑'s!)
• visible in the process list showing up in top, etc,
• and synced (fairly insecurely!) to all my machines, even ones I wouldn't normally install my 1Password on.

Just a thought!

At least offering the option of passing it like the master password — on stdin / the tty — would be great for my peace-of-mind. :<3:

---

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

rickfillion

Thanks @ELLIOTTCABLE, we'll keep that in mind.

I'm curious to know what you're using to sync between your machines?

Rick

bzd

Hi,
I'm seriously considering 1password for a family subscription. I've used Enpass for a while and quite like it but it's less cost-effective across a largish family (and doesn't have the family management features).
My only problem is that I'm a linux/firefox user at home and work, and I'm not willing to let the tail wag the dog, so to speak.
The CLI however might just be enough to make me subscribe but I share Elliot's concern about putting the secret-key on the command-line makes it, well, essentially not secret. Whilst the process is running this is readily available to any other user who can run ps (i.e. any other user!), and also it will be saved in the clear on disk in e.g. .bash_history.
One way round the latter is to install csh and only run it in a csh environment (no history) but this isn't a good workaround. The ps listing is a genuine security hole and I would urge you to allow a non-command-line-option way of entering the secret key!

MrC

@bzd,

FYI:

$ man bash

   HISTCONTROL
          A  colon-separated  list of values controlling how commands are saved on the history list.  If the list of values includes ignores-
          pace, lines which begin with a space character are not saved in the history list.  A value of ignoredups causes lines matching  the
          previous  history  entry to not be saved.  A value of ignoreboth is shorthand for ignorespace and ignoredups.  A value of erasedups
          causes all previous lines matching the current line to be removed from the history list before that line is saved.  Any  value  not
          in  the  above list is ignored.  If HISTCONTROL is unset, or does not include a valid value, all lines read by the shell parser are
          saved on the history list, subject to the value of HISTIGNORE.  The second and subsequent lines of a  multi-line  compound  command
          are not tested, and are added to the history regardless of the value of HISTCONTROL.

bzd

@MrC That is a good workaround (for the history anyway) :chuffed:
The ps listing is the main concern though.

rickfillion

@bzd : one workaround you can use is to simply create/copy your ~/.op/config. You can manually add your account there in the accounts array

        {
            "shorthand": "blah",
            "url": "https://blah.1password.com",
            "email": "[email protected]",
            "accountKey": "A3-HTBX87-9VZC73-QFFT6-9EBAV-L66V7-G33HB",
        }

Then you can use op signin blah without needing to input your secret key on a command.

Rick

bzd

@rickfillion That's a reasonable alternative for avoiding the ps listing. I have to admit to not having used op properly yet (I'm still considering the options) but I'd been hoping to not have a copy of the secret key stored anywhere on disk or network accessible but having it stored only on an encrypted partition is mostly there! Maybe on an encrypted USB stick with a suitable symbolic link from ~/.op/config is what I should do! :)
Thanks for the info!

rickfillion

@bzd : unfortunately there's nothing available to us locally in order to encrypt the secret key ourselves.

The symlink to encrypted storage is a neat idea, but if the concern is that the secret key can show up in ps output the first time that you need to use it (it wouldn't show up in any other case) then it sounds like you're trying to protect against other users on this system. So you'll need to make sure that the permissions on that encrypted storage also protect against read access from those other users. If it's really just other users that you're concerned about, then a non-symlinked ~/.op/ dir with proper permissions (the ones we set by default) would also do the trick.

Rick

bzd

Thanks for all the suggestions. I guess I'm good to go... Now to get the rest of the family on board :)

cohix

Great to hear it! Let me know how the experience goes.