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

31–40 of 77 posts

Re: How to handle secrets on the command line

#31

Post by LadyCailin »

nijave wrote: post #29
LadyCailin wrote: post #21

In the programming language I’m working on, MethodScript, I’ve created a subclass of string, secure_string. The normal print value is “secure string”. Unlike somewhat equivalent classes in other languages, this is a subclass of string, which means it can be passed around opaquely to things that only accept strings, but then the functions that actually need to be aware of secrets can check for the subclass and call th…

.NET (and PowerShell) have something similar. Interestingly, Microsoft recommends not using them. https://github.com/dotnet/platform-compat/blob/master/docs/D... I assume by certs and Windows auth they're implying the OS native stuff versus just passing those around in code, instead

The key difference though is that mine is a subclass of string. I am aware of these in other languages, but they can’t be used in place of strings.

Re: How to handle secrets on the command line

#32

Post by LadyCailin »

Hjfrf wrote: post #28
LadyCailin wrote: post #21

In the programming language I’m working on, MethodScript, I’ve created a subclass of string, secure_string. The normal print value is “secure string”. Unlike somewhat equivalent classes in other languages, this is a subclass of string, which means it can be passed around opaquely to things that only accept strings, but then the functions that actually need to be aware of secrets can check for the subclass and call th…

Sounds similar to Powershell's SecureString, if you want to compare vs a non-"toy" equivalent.

In isolation, yes, but my version is a subclass of string, which adds another layer of functionality on top of the base feature set.

Re: How to handle secrets on the command line

#33

Post by kamil3141 »

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…

It’s not unobtrusive on mobile :(

Re: How to handle secrets on the command line

#34

Post by __zack »

LadyCailin wrote: post #21

In the programming language I’m working on, MethodScript, I’ve created a subclass of string, secure_string. The normal print value is “secure string”. Unlike somewhat equivalent classes in other languages, this is a subclass of string, which means it can be passed around opaquely to things that only accept strings, but then the functions that actually need to be aware of secrets can check for the subclass and call th…

> the functions that actually need to be aware of secrets can check for the subclass

I feel like this is an antipattern in OOP. Shouldn’t the functions just be defined to take in parameters of type SecureString instead?

I think this violates the liskov substitution principle (https://en.m.wikipedia.org/wiki/Liskov_substitution_principl...). For example, how is the “length” function or “startsWith” defined on SecureString? It seems like either data would be leaked via side channels, or the behavior doesn’t really conform to the String specification.

Re: How to handle secrets on the command line

#35

Post by throwawaaarrgh »

While the author is correct that you can leak secrets that other users could see, in modern systems you can avoid accidental leaks via containers or host OS modifications.

If you're using containers, only other users in your container will be able to see leaked secrets. Typically there's only one user in a running container. If an application in the container gets hacked, the whole thing is vulnerable anyway, leaks or not. Or if the container was running in privileged mode, which compromises host security. If someone gets access to your Docker host, or root access on the Docker host (privilege escalation to root is pretty trivial on Linux) then they can see all information, leaked or not.

If you aren't using containers, and just a regular Linux OS, a couple methods exist to harden process information between users (such as cmdline and environ) to contain most of the leaks.

What you do want to avoid is writing secrets to persistent storage, or filesystems that many different containers or users can access. You also want to prevent passing secrets to containers as environment variables, as your orchestration system might expose them to more users accidentally, and some logging systems might log them.

The best practice for passing secrets into a container is to have your container orchestration system pass credentials to the container, such as with an instance metadata service, or temporary volume-mounted secrets filesystems. The container would use that passed credential to then access a secrets manager.

Re: How to handle secrets on the command line

#36

Post by tiziano88 »

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…

> opt-out by default

That's the definition of opt-in

Re: How to handle secrets on the command line

#37

Post by contravariant »

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?

Well uBlock can't block all cookie warnings, some of them are more than just cosmetic. And uBlock doesn't remove the cookies if any get through.

Re: How to handle secrets on the command line

#38

Post by formerly_proven »

matja wrote: post #15
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).

On Linux, the permissions on /proc/$PID/environ are the same permissions you'd need to read the memory of the process, so just being able to list that dirent doesn't give you anything. Though I do think that command lines being visible to other users is a design flaw.

Re: How to handle secrets on the command line

#39

Post by gumby »

_odey wrote: post #4

You have envchain to store secrets as ENV variables in your keyring and execute commands: https://github.com/sorah/envchain Not really something you would use for production web apps, I think envconsul covers that usecase: https://github.com/hashicorp/envconsul

ENV vars are global variables; they will be visible to all the child processes as well unless care is taken. Is that really worth it?

Re: How to handle secrets on the command line

#40

Post by imiric »

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…

That's strange. Maybe it defaults to opt-out only in the EU?

While it's not entirely unobtrusive, especially on mobile, it's far better than similar forms on most other sites that usually take up the bottom half of the screen, or block the content entirely behind a modal dialog.

> As well as "Continue to site", it has buttons for "Policies", ...

Those others aren't buttons, but links, and small ones. The most prominent element is the single button that dismisses the dialog and is actually safe to click. If you've seen most other consent forms, rejecting cookies (if possible at all) is usually done via a small link next to a prominent "Accept all" button and other such dark patterns.

So this is a great UX improvement, though I agree with you that all these forms are obnoxious and we should get rid of them. Unfortunately it's the best we currently have to mitigate this abuse legally (at least in the EU).

Also, I'd be fine with some non-essential cookies for e.g. analytics, as long as this is not shared with 3rd parties, so no Google Analytics and such, but few sites implement it that way.

Though TBH all this feels like privacy theater. There are more sophisticated ways than cookies for tracking users that aren't being discussed nearly as much, yet are probably already widely used.

Post reply on HN