> 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.
Not working well with something that doesn't conform to the WICG User-Agent Client Hints specification is an interesting definition of "closed." More like, "I have standards." And it's hardly closed if you can get the information by using literally almost any other client.
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.
Interesting approach. I like Docker/Kubernetes way of secret mounts where you can limit user/group permissions too.
Meanwhile, I was an avid user of the echo secret | ssh consume approach, specifically for the kerberos authentication.
In my workflow, I saved the kerberos password to the macOS keychain, where kinit --use-keychain authenticated me seamlessly. However this wasn't the case for remote machines.
Therefore, I have implemented a quick script that is essentially
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.
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.
Interesting article. What prevents me from dumping the memory of the shell process and reading the local variable?
My program requires a password on startup. To run it in a loop, I used a script that takes the password as input, stores it in a local variable, and echoes it to the program. At the time I thought the only weakness was the memory of the shell process. But it was the best I could come up with.
11 comments
[ 3.0 ms ] story [ 31.7 ms ] threadThe world doesn't exclusively use Chrome. Nice to see even the nerds are contributing to the closed web.
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.
Meanwhile, I was an avid user of the echo secret | ssh consume approach, specifically for the kerberos authentication.
In my workflow, I saved the kerberos password to the macOS keychain, where kinit --use-keychain authenticated me seamlessly. However this wasn't the case for remote machines.
Therefore, I have implemented a quick script that is essentially
Which served me really good for the last 4~years.man keyctl
* Well, one of the correct ways of doing this.
My program requires a password on startup. To run it in a loop, I used a script that takes the password as input, stores it in a local variable, and echoes it to the program. At the time I thought the only weakness was the memory of the shell process. But it was the best I could come up with.