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

51–60 of 77 posts

Re: How to handle secrets on the command line

#51

Post by croes »

mkl wrote: post #27
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…

That's not what I experienced. Is it just way worse for different locations (NZ here)? It's not opt-out by default; I had to turn off advertising and analytics cookies manually. The cookie consent pop-up takes up a third of a big mobile screen. As well as "Continue to site", it has buttons for "Policies", "Preferences", "Do not sell my personal information", and "Powered by CLM". Cookie pop-ups need to die. Non-essen…

Cookie banners and pop-ups only exist to make the GDPR look bad.

Re: How to handle secrets on the command line

#52

Post by jspielberg »

tl;dr - If worried about leaking the path to a secret file, use Sorry for the top level comment, but I am surprised this hasn't been shared by someone else already. Process substitution(1) (e.g. From RTFA, the author is using "$(For example... lets say for an arbitrary example, I didn't want folks knowing from the process table that I was getting the file details of /etc/passwd

  ### LEAKY
  ~ % wc /etc/passwd 
     110     297    6946 /etc/passwd
I could instead use process substitution:

  % wc
I have found this to be most useful not for files, but for temporary secret variables that I want to wrap in a file, but not have to deal with the cleanup and management of that file.

For a shell variable example, rather than writing "B64 is not encryption" to a file, and then having to cleanup that file... use process substitution to create the temporary file which doesn't leak to the process table.

  ## Don't do :
  ~ % echo  "B64 is not encryption" | base64  
  QjY0IGlzIG5vdCBlbmNyeXB0aW9uCg==

  ## Do this instead; also 'echo' is a bash builtin and won't leak
  ~ % base64
Or if used in scripting:

  secret="B64 is not  encryption"
  bar="$(base64
Some caveats: This only works for commands that accept files for arguments. If a command requires a secret to be passed in as a plaintext argument, then maybe the right answer is to rethink using that command in the first place (maybe PROTIP: And for the love of all that's holy... run shellcheck(3) before considering running your script for realz if you want to keep your butt out of the fire. Also, the google shell style guide (4) is full of practical/good stuff. Shellcheck and the google style guide are pretty magical. I lost 10 lbs without dieting, became more attractive, and married my wife from following the guidance from those two resources. You can too! (caveat lector, ymmv, not legal advice (ianal), wife is already taken... sorry)

--- (1) https://www.gnu.org/software/bash/manual/html_node/Process-S... (2) https://en.wikipedia.org/wiki/Here_document#Here_strings (3) https://github.com/koalaman/shellcheck (4) https://google.github.io/styleguide/shellguide.html

Re: How to handle secrets on the command line

#54

Post by vkomega »

I have been asking myself lately:

Without considering resources or practicality, if we were to re-design computers and servers from security-first principles, what would features like management of secrets look like? Secure enclaves are wonderful but the secret still has to be propagated or used. A ground up computer design might greatly embellish on the idea of a secure enclave.

Linux seems a bit of a dinosaur in this regard.

Re: How to handle secrets on the command line

#55

Post by NelsonMinar »

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? :)

Oh oh I know this! Ultrix 2.2 in 1990 did this. Not via /proc, which did not exist in that OS, but via the ps command. From the Ultrix Security Guide for Users:

"Note that denying other users read permission [to your .profile] does not mean that they cannot find your PATH or any other of your environment variables. The -eaxww options to the ps command display in wide format the environment variables for all processes on the system"

Ultrix 2.2 was a BSD 4.2 variant by DEC. I doubt it was unique in this behavior, my guess is all BSDs leaked info in this way, but I don't have a reference handy. mkj's example in this thread of AIX suggests Sys V did it too. Modern Linux only shows you your own processes' environment variables.

(Young people of Hacker News: beware what operating systems you learn because 31 years later their idiosyncracies will still be burned into your brain.)

Re: How to handle secrets on the command line

#56

Post by NovemberWhiskey »

vkomega wrote: post #54

I have been asking myself lately: Without considering resources or practicality, if we were to re-design computers and servers from security-first principles, what would features like management of secrets look like? Secure enclaves are wonderful but the secret still has to be propagated or used. A ground up computer design might greatly embellish on the idea of a secure enclave. Linux seems a bit of a dinosaur in th…

The usual problems apply: identity, authentication, authorization, roots of trust.

Imagine your enclave is a separate server on the network: how do you define which processes get access to which secrets under which circumstances? How do processes prove who they are to the enclave?

Re: How to handle secrets on the command line

#57

Post by tyingq »

vkomega wrote: post #54

I have been asking myself lately: Without considering resources or practicality, if we were to re-design computers and servers from security-first principles, what would features like management of secrets look like? Secure enclaves are wonderful but the secret still has to be propagated or used. A ground up computer design might greatly embellish on the idea of a secure enclave. Linux seems a bit of a dinosaur in th…

>Linux seems a bit of a dinosaur in this regard

To be fair, it has only whatever is on-hand to use. And the burden of running in a lot of different environments. Apple, having control of the hardware, and a very specific/limited set of places to run, can do smarter things around enclaves, etc.

Re: How to handle secrets on the command line

#58

Post by user3939382 »

user3939382 wrote: post #41

I use a LastPass CLI client that I can pass in to other scripts or bash functions like my frequently used SSH invocations. Works great. Edit: Here’s a link https://github.com/lastpass/lastpass-cli

You can also use the macOS Keychain directly from the command line. This isn't the guide I originally used but gives you an idea: https://www.netmeister.org/blog/keychain-passwords.html

Re: How to handle secrets on the command line

#59

Post by vkomega »

NovemberWhiskey wrote: post #56
vkomega wrote: post #54

I have been asking myself lately: Without considering resources or practicality, if we were to re-design computers and servers from security-first principles, what would features like management of secrets look like? Secure enclaves are wonderful but the secret still has to be propagated or used. A ground up computer design might greatly embellish on the idea of a secure enclave. Linux seems a bit of a dinosaur in th…

The usual problems apply: identity, authentication, authorization, roots of trust. Imagine your enclave is a separate server on the network: how do you define which processes get access to which secrets under which circumstances? How do processes prove who they are to the enclave?

Maybe the idea of an OS with processes running on a single interconnected silicon is part of the issue, too. Just brainstorming based on your response.

Re: How to handle secrets on the command line

#60

Post by atkailash »

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…

I use sops for my dot files. There’s some oddities if you want to commit only an encrypted one to git and use a sops.yaml but not a big deal. Hadn’t thought of using it for local only use in this sort of thing, but is a good idea
Post reply on HN