Comment by febusravenga
8 hours ago
this, this, this
All our tokens should be in is protected keychain and there are no proper cross-platform solutions for this. All gclouds, was aww sdks, gh and other tools just store them in dotfile.
And worst thing, afaik there is no way do do it correctly in MacOS for example. I'd like to be corrected though.
What is a proper solution for this? I don't imagine gpg can help if you encrypt it but decrypt it when you login to gnome, right? However, it would be too much of a hassle to have to authenticate each time you need a token. I imagine macOS people have access to the secure enclave using touch ID but then even that is not available on all devices.
I feel like we are barking up the wrong tree here. The plain text token thing can't be fixed. We have to protect our computers from malware to begin with. Maybe Microsoft was right to use secure admin workstations (saw) for privileged access but then again it is too much of a hassle.
The way I solve the plain text problem is through a combination of direnv[1] and pass[2].
For a given project, I have a `./creds` directory which is managed with pass and it contains all the access tokens and api keys that are relevant for that project, one per file, for example, `./creds/cloudflare/api_token`. Pass encrypts all these files via gpg, for which I use a key stored on a Yubikey.
Next to the `./creds` directory, I have an `.envrc` which includes some lines that read the encrypted files and store their values in environment variables, like so: `export CLOUDFLARE_API_TOKEN=$(pass creds/cloudflare/api_token)`.
Every time that I `cd` into that project's directory, direnv reads and executes that file (just once) and all these are stored as environment variables, but only for that terminal/session.
This solves the problem of plain-text files, but of course the values remain in ENV and something malicious could look for some well known variable names to extract from there. Personally I try to install things in a new termux tab every time which is less than ideal.
I'd like to see if and how other people solve this problem
[1]: https://direnv.net/ [2]: https://www.passwordstore.org/
At least with direnv your exports are removed when you leave the directory.
You can even go further and delete all your secrets from your env by creating wrapper scripts
Example : https://github.com/combostrap/devfiles/blob/main/dev-scripts...
It’s not completely full proof but at least gpg asks my passphrase only when I run the script
It might be possible to lash up a cross-plaform solution with KeePassXC. It's got an API that can be accessed from the command line (chezmoi uses it to add secrets to dotfiles). Yes, you'd be authenticating every time you need a token but that might not be too much of a burden if you spend most of your time on a machine with a fingerprint scanner.
otoh I wouldn't do it, because I don't believe I could implement it securely.
I’ve got this work 1password setup, the only issue is if you have background tasks.
I had a Borg backup script for example and 1password needed me to authenticate to run it.
Authenticating for ssh and git is great.
I think the correct solution is to use a keyring. On Linux there's gnome keyring and last time I worked on a IOS app there was something similar.
This does mean entering your keyring password a lot.
https://en.wikipedia.org/wiki/GNOME_Keyring
> This does mean entering your keyring password a lot.
Not when you put that keyrings password into the user keyring. I think it is also cached by default.
1 reply →
For what it’s worth, the recommended way of getting credentials for AWS would be either:
1. Piggyback of your existing auth infra (eg: ActiveDirectory or whatever you already have going on for user auth) 2. Failing that use identity center to create user auth in AWS itself
Either way means that your machine gets temporary credentials only
Alternatively, we could write an AWS CLI helper to store the stuff into the keychain (maybe someone has)
Not to take away from your more general point
We need flatpak for CLI tools
This doesn't sound like a technical problem to me. Even my throw-away bash scripts call to `secret-tool lookup`, since that is actually easier than implementing your own configuration.
Also this is a complete non-issue on Unix(-like) systems, because everything is designed around passing small strings between programs. Getting a secret from another program is the same amount of code, as reading it from a text file, since everything is a file.
> no way do do it correctly in MacOS
What? The MacOS Keychain is designed exactly for this. Every application that wants to access a given keychain entry triggers a prompt from the OS and you must enter your password to grant access.