←back to thread

1208 points jamesberthoty | 1 comments | | HN request time: 0.207s | source
Show context
madeofpalk ◴[] No.45260948[source]
My main takeaway from all of these is to stop using tokens, and rely on mechanisms like OIDC to reduce the blast radius of a compromise.

How many tokens do you have lying around in your home directory in plain text, able to be read by anything on your computer running as your user?

replies(1): >>45261000 #
diggan ◴[] No.45261000[source]
> How many tokens do you have lying around in your home directory in plain text, able to be read by anything on your computer running as your user?

Zero? How many developers have plain-text tokens lying around on disk? Avoiding that been hammered into me from every developer more senior than me since I got involved with professional software development.

replies(5): >>45261018 #>>45261050 #>>45261136 #>>45261146 #>>45261317 #
pjc50 ◴[] No.45261146[source]
Isn't this quite hard to achieve on local systems, where you don't have a CI vault automation to help?
replies(4): >>45261330 #>>45261623 #>>45262118 #>>45269012 #
1. 0xbadcafebee ◴[] No.45269012[source]
Most popular apps today have integrations to allow reading secrets from external programs. If not, they can take them from environment variables. Both those can then be loaded from a password manager, so the secret never lands on disk in plaintext.

Your program (or your shell) opens. It runs a program to ask the password manager for a secret. Your password manager prompts you to authorize unsealing the secret. You accept or deny. The secret is passed to the program that asked for it. Works very well with 1Password and tools like git, ssh, etc, or simply exporting the secret to an environment variable, either in a script or bashrc file.

Other programs also support OIDC, such as with git credential helper plugins, or aws sso auth.