←back to thread

1208 points jamesberthoty | 1 comments | | HN request time: 0.224s | 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 #
madeofpalk ◴[] No.45261050[source]
You're sure you don't have something lying around in ~/.config ? Until recently the github cli would just save its refresh token as a plain text file. AWS CLI loves to have secrets sitting around in a file https://docs.aws.amazon.com/cli/latest/userguide/cli-configu...
replies(1): >>45261098 #
1. diggan ◴[] No.45261098[source]
I don't use AWS and looking in ~/.config/gh I see two config files, no plain-text secrets.

With that said, it's not impossible some tool leaks their secrets into ~/.local, ~/.cache or ~/.config I suppose.

I thought they were referencing the common approach of adding environment variables with plaintext secrets to your shell config or as an individual file in $HOME, which been a big no-no for as long as I can remember.

I guess I'd reword it to "I'm not manually putting any cleartext secrets on disk" or something instead, if we wanted it to be 100% accurate.