Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to handle secrets on the command line

smallstep.com

Post reply on HN
Print view View original

11–20 of 77 posts

Re: How to handle secrets on the command line

#11

Post by kenty »

imiric wrote: post #9

Sidenote: I really like the cookie consent form on this site. It's unobtrusive, clear, opt-out by default and the highlighted and only button is "Continue to site". And it even has a built-in GDPR request form! Bravo to https://www.clym.io/ Nice article, covers the basics well. Credential files seem like simplest way to go and are secure enough for most local uses. For anything more involved a secrets manager is prob…

About the cookie: just install the extensions `CookieAutoDelete` and `I don't care about cookies`. No more cookie warnings, no more privacy problems. About the article: TL;DR: use a secrets file.

Re: How to handle secrets on the command line

#12

Post by williamvds »

Dealing with secrets on a Linux desktop is quite a mess right now. E.g. for my SSH and GPG keys I use some concoction of gnome-keyring and gpg-agent, and I must admit I don't really understand how it works. Himitsu[0] is an interesting approach to a secrets manager. It apparently uses an "agent" to do authentication/whatever and passes on the resource to the application that requested it, meaning applications don't have to touch the secrets themselves.

[0] https://git.sr.ht/~sircmpwn/himitsu

Re: How to handle secrets on the command line

#13

Post by klntsky »

kenty wrote: post #11
imiric wrote: post #9

Sidenote: I really like the cookie consent form on this site. It's unobtrusive, clear, opt-out by default and the highlighted and only button is "Continue to site". And it even has a built-in GDPR request form! Bravo to https://www.clym.io/ Nice article, covers the basics well. Credential files seem like simplest way to go and are secure enough for most local uses. For anything more involved a secrets manager is prob…

About the cookie: just install the extensions `CookieAutoDelete` and `I don't care about cookies`. No more cookie warnings, no more privacy problems. About the article: TL;DR: use a secrets file.

How is that different/better than uBlock with annoyances filters turned on?

Re: How to handle secrets on the command line

#14

Post by okamiueru »

No mention of `pass`? Certainly solves all my needs, and works well for version controlling secrets across a team.

The only annoying thing about `pass` is the generic name, so searching for information on it, or dealing with issues is a pita. Luckily, there are few.

Edit: I was wrong about what this article covers. Which is how to pass secrets to processes without leaking to `ps` or audit log.

----

Pass is still worth a look, https://www.passwordstore.org/

Keeping the password storage in a gitlab repo makes it very useful for managing those secrets internally. Keep the list of public gpg keys for each team member, and a README, some helping initialization script for setting it up, and that's pretty much it.

Then, all cases presented where the command would either be used directly in the command line, or within another script, is just replaced with a call to

  $(pass the/secret/we/need)

Re: How to handle secrets on the command line

#15

Post by matja »

formerly_proven wrote: post #2

> Some operating systems still make every process’s environment variables world readable. (But, in all the Linuxes I’ve seen, /proc/ /environ is not world-readable.) A couple years ago this came up and someone made this claim, but no one could ever name an OS where this is the case. Maybe someone on HN knows one? :)

The procfs hidepid option still defaults to 0 (visible), but systemd will set it to 2 (invisible).

Re: How to handle secrets on the command line

#16

Post by maweki »

okamiueru wrote: post #14

No mention of `pass`? Certainly solves all my needs, and works well for version controlling secrets across a team. The only annoying thing about `pass` is the generic name, so searching for information on it, or dealing with issues is a pita. Luckily, there are few. Edit: I was wrong about what this article covers. Which is how to pass secrets to processes without leaking to `ps` or audit log. ---- Pass is still wort…

How does pass solve this problem? Surely entering "command `pass accountdata`" has the same problem that the secret shows up in ps as command's argument.

Re: How to handle secrets on the command line

#17

Post by failwhaleshark »

If the concerns are just shell history and process info:

On macOS, you can use pbcopy and pbpaste from/to the clipboard. On Linux, that's:

    alias pbcopy='xclip -selection clipboard'
    alias pbpaste='xclip -selection clipboard -o'
Or use secret files or something like Vault for automation.

Re: How to handle secrets on the command line

#18

Post by okamiueru »

maweki wrote: post #16
okamiueru wrote: post #14

No mention of `pass`? Certainly solves all my needs, and works well for version controlling secrets across a team. The only annoying thing about `pass` is the generic name, so searching for information on it, or dealing with issues is a pita. Luckily, there are few. Edit: I was wrong about what this article covers. Which is how to pass secrets to processes without leaking to `ps` or audit log. ---- Pass is still wort…

How does pass solve this problem? Surely entering "command `pass accountdata`" has the same problem that the secret shows up in ps as command's argument.

I see. I should have read the article more closely before commenting. I made a bad assumption based on the comments I saw here. The article is more about avoiding leaking the password than actually dealing with managing passwords in command lines.

A few comments on the actual article, which was a lot more insightful than I had thought:

- Protecting yourself from an audit logs is not really worth the effort, as the audit log should be treated as confidential as the secrets themselves.

- Utilities can themselves hide arguments, and will not show on the ps output. For example, `mysqlsh` shows as `--password=********`, as does `mysql`. I'm not 100% if modifying argv data has any effect on /proc, but then again, if you are protecting yourself from something that can access /proc (i.e. root), then nothing will work in the end. Protecting yourself from a rogue process that can monitor `ps` is also already a lost battle.

Re: How to handle secrets on the command line

#19

Post by vbezhenar »

failwhaleshark wrote: post #17

If the concerns are just shell history and process info: On macOS, you can use pbcopy and pbpaste from/to the clipboard. On Linux, that's: alias pbcopy='xclip -selection clipboard' alias pbpaste='xclip -selection clipboard -o' Or use secret files or something like Vault for automation.

wl-copy/wl-paste from wl-clipboard package for Linux/Wayland.

Re: How to handle secrets on the command line

#20

Post by joosters »

klntsky wrote: post #13
kenty wrote: post #11

Earlier quoted context omitted.

About the cookie: just install the extensions `CookieAutoDelete` and `I don't care about cookies`. No more cookie warnings, no more privacy problems. About the article: TL;DR: use a secrets file.

How is that different/better than uBlock with annoyances filters turned on?

Auto-deleting cookies means that you don’t need a filter list to block bad sites, every site will be wiped. There’s no chance that a missed site will sneak through.

The downside is that you will need to whitelist every site that you want to remember your login/settings for when revisiting them.

Post reply on HN