Live data from Hacker News

How to handle secrets on the command line

smallstep.com

21–30 of 77 posts

Re: How to handle secrets on the command line

#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 the special decryption method. The string is encrypted in memory, but this is really just obscurity, because the decryption key is there too. But it does prevent most logging from ever leaking the secret, including things like memory dumps. I wish mainstream languages had a feature like this, since MethodScript is still fairly far in the “toy” category for now.

Re: How to handle secrets on the command line

#23

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…

Should be fairly straightforward to implement in say Python?

Re: How to handle secrets on the command line

#24
post #13

Earlier quoted context omitted.

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.

You can achieve that by just using incognito mode. Though the extension would surely be more flexible.

Still, I haven't used a browser extension in years, partly because of extensions like this that require access to all browsing data, even if they're open source like in this case (though the author of "I don't care about cookies" has a strange concept of distribution[1]). The inconvenience of wiping cookies and clicking through cookie consent forms is much more tolerable than allowing random extensions access to all my browsing data.

[1]: https://teddit.net/r/privacy/comments/bru6wd/p/eohtox3/

Re: How to handle secrets on the command line

#25
post #16

Earlier quoted context omitted.

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 au…

> if you are protecting yourself from something that can access /proc (i.e. root)

on Linux and all other Unix-like systems I know of, all users are allowed to list running processes and their command lines.

> Protecting yourself from a rogue process that can monitor `ps` is also already a lost battle.

ps is not a privileged command on most systems. POSIX says "On some implementations, especially multi-level secure systems, ps may be severely restricted and produce information only about child processes owned by the user."; "severely restricted" implies that this is not a common behavior.

furthermore, the article explains clearly how to hide secret arguments from ps. that's the main point of the article.

Re: How to handle secrets on the command line

#26
it's not the main point of the article, but curl -X is being misused here. as the manual explains, "Normally you don't need this option. All sorts of GET, HEAD, POST and PUT requests are rather invoked by using dedicated command line options." https://daniel.haxx.se/blog/2015/09/11/unnecessary-use-of-cu... reiterates the issue, along with a reminder that -X persists past redirects (hope your API doesn't redirect to a completion page).

after searching for "PUT" in the manual, I found "-T, --upload-file [...] If this is used on an HTTP(S) server, the PUT command will be used. Use the file name "-" (a single dash) to use stdin instead of a given file."

Re: How to handle secrets on the command line

#27
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-essential cookies aren't to "improve your experience", they're usually for invasive tracking, and if a site only uses strictly necessary cookies, even the GDPR doesn't require explicit consent.

Re: How to handle secrets on the command line

#28

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.

Re: How to handle secrets on the command line

#29

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

Re: How to handle secrets on the command line

#30

I wrote a simple oh-my-zsh (but should be easy to port out) plugin to improve UX of the environment variables option [0]. It's basically a very simple secrets manager, allowing one to store env variables (or whole chunks of scripts) in GPG-encrypted files and see if any secrets are sourced at the moment. So the workflow usually looks like following: $ secrets aws-credentials # prompts a GPG passphrase $ aws s3 sync .…

If you use `pass` I wrote a little plugin to export the values as environmental variables in a simple and consistent fashion: https://blog.steve.fi/password_store_plugin__env.html

Nice, I do this via a small script:

  env $(pass env/$1) ${@:2}
Post reply on HN