FRESH

Hacker News

I prefer to pass secrets between programs through standard input

61 points by ingve

by kevin_thibedeau

7 subcomments

> Unfortunately you're using a browser (or client library) that my anti-crawler precautions consider suspicious because it's sending inconsistent values for Sec-CH-UA-* HTTP request headers...
The world doesn't exclusively use Chrome. Nice to see even the nerds are contributing to the closed web.

by azornathogron

2 subcomments

For one of my projects my server needs a private key, and it reads this from a file descriptor on startup and then closes the fd. The fd is set up by the systemd unit, which is also configured to restrict filesystem access for the server. So the server reads a key from a file that is never visible in its mount namespace.

by juancn

0 subcomment

I used to do that, I had a sort of IDE that launched a local server, bound to localhost.
The launching process would send a random password through stdin to the child after launch, and the child would use that to authenticate the further RPC calls.
It's surprisingly hard to intercept a process' stdin stream.

by Dwedit

3 subcomments

I haven't actually tested this, but aren't the input and output handles exposed on /proc/? What's stopping another process from seeing everything?

by pvtmert

0 subcomment

by blibble

0 subcomment

by Spivak

0 subcomment

For your actual production systems you might consider systemd-creds along with the LoadCredential= and LoadCredentialEncrypted= directives which do the* right thing. Nothing is exposed and credentials are placed in non-swappable memory. You can even have your credentials encrypted at rest with your system's TPM.
* Well, one of the correct ways of doing this.

by stale-labs

1 subcomments