[febusravenga]

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.

[mcny]

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.

[sakisv]

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/

[gerardnico]

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

[hrimfaxi]

At least with direnv your exports are removed when you leave the directory.

[internet_points]

but if you `cd project && npm install compromised-package` then compromised-package's setup script can still read your env vars, right?

[tinodb]

Yes, but I guess that is still much better than that it can read all your .env files on your machine

[L-four]

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

[1718627440]

> 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.

[masfuerte]

Then what stops the malware accessing the keyring?

[1718627440]

The security boundary on the OS is the user of the process. If you run the malware under the same user as the key, than yes of course it has access. But in production you don't run software under the same user, and on the developer machine you wouldn't put the production key in the user keychain.

[mxey]

On disk, it’s encrypted. The running service, at least on macOS, only hands the item out to specific apps, based on their code signing identity.

[ElectricalUnion]

Who signs an "app" when I download it from Homebrew?

If all Homebrew "apps" are the same key then accepting a keyring notification on one app is a lost cause at it would allows things vulnerable to RCE to read/write everything?

[flir]

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.

[data-ottawa]

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.

[__turbobrew__]

Yubikey/TouchID

[mxey]

> And worst thing, afaik there is no way do do it correctly in MacOS for example. I'd like to be corrected though.

https://developer.apple.com/documentation/security/keychain-...

And similar services exist on Linux desktops. There are libraries that will automatically pick the right backend.

[akdev1l]

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

[queenkjuul]

Snap works with CLI tools. But underneath that, isn't it AppArmor and namespaces? (I don't really know. I'm getting the impression flatpak-style process isolation is possible just not widely adopted)

[1718627440]

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.

[naikrovek]

> 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.