Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

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?

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

How do you manage secrets for your projects?

Using a password manager for fetching them when needed. 1Password in my case, but I'm sure any password manager can be used for storing secrets for most programming projects.

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

Which programming languages/frameworks do you use? Do you use 1Password to load secrets to env where you run whatever thing you are working on? Or does the app load them during boot?

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.

A bunch, ranging from JS to Clojure and everything in-between, depends on the project.

The approach also depends on the project. There is a bunch of different approaches and I don't think there is one approach that would work for every project, and sometimes I requires some wrangling but takes 5-10 minutes tops.

Some basic information about how you could make it work with 1Password: https://developer.1password.com/docs/cli/secrets-environment...

> How many developers have plain-text tokens lying around on disk?

Most of them. Mainly on purpose, (.env files) but many also accidentally. (shell history with tokens in the commands)

Isn't this quite hard to achieve on local systems, where you don't have a CI vault automation to help?

One option is pass, which is a shell script that uses GPG to manage passwords for command line tools. You can put the password store into a git repository if you need to sync it across machines.

A good habit, but encryption won't save you in all cases because anything you run has write access to .bashrc.

Frankly, our desktop OSes are not fit for purpose anymore. It's nuts that everything I run can instantly own my entire user account.

It's the old https://xkcd.com/1200/ . That's from 2013 and what little (Flatpak, etc.) has changed has only changed for end users - not developers.

How long have you been using that method? I didn't feel it's been very popular so far, although it makes a lot of sense. I've always seen people using gitignored .env files/config dirs in projects with many hardcoded credentials.

I don't think so? I don't even know what a "CI vault automation" is, I store my credentials and secrets in 1Password, and use the CLI to get the secrets for the moments they're needed, I do all my development locally and things seem fine.

Wait, what? "put the password store into a git repository"?!

Fun fact : Bitwarden’s cli is written in JavaScript and needs Node.js to run.

I was thinking about one more case, if you are using 1password as a cli tool. Let's say you "op run -- npm dev". If there's a malicious node modules script, it would of course be able to get the env variables you intended to inject, but would it also be able to continue running more op commands to get all your other secrets too if you have started a session?

Edit: Testing 1Password myself, with 1password desktop and shell, if I have authed myself once in shell, then "spawn" would be able to get all of my credentials from 1Password.

So I'm not actually sure how much better than plaintext is that. Unless you use service accounts there.

It's not that hard if it's something you decide you care about and want to solve. Like diggan mentions, there's many tools, some you already might use, that can be used to inject secrets into applications that's not too onerous to use in your development workflow.

I'd argue the reverse is true. On your local system, which only need to operate when a named user with a (hopefully) strong password is present, you can encrypt the secrets with the user's login password and the OS can verify that it's handing the secret out to the correct binary before doing so. The binary can also take steps to verify that it is being called directly from a user interaction and not from a build script of some random package.

The extent to which any of this is actually implemented varies wildly between different OSes, ecosystems and tools. On macOS, docker desktop does quite well here. There's also an app called Secretive which does even better for SSH keys - generating a non-exportable key in the CPU's secure enclave. It can even optionally prompt for login password or fingerprint before allowing the key to be used. It's practically almost as secure as using a separate hardware token for SSH but significantly more convenient.

In contrast, most of the time the only thing protecting the keys in your CI vault from being exfiltrated is that the malware needs to know the specific name / API call / whatever to read them. Plenty of CI systems you don't even need that, because the build script that uses the secrets will read them into environment variables before starting the build proper.

The store in the case of pass, is a plain text file, whose contents are encrypted strings. If you trust the encryption, you can put it anywhere you like. Keep the keys secret and safe, though!

Until you have to fire one of your disgruntled employees, who has a copy of all your secrets that you now need to rotate.

A repository that an attacker only needs to get access to once, after which they can perform offline attacks against at their leisure.

A repository that contains the history of changed values, possibly making the latter easier, if you used the same encryption secret for rotated values.

This is an awful idea. Use a proper secret management tool you need to authenticate to using OIDC or Passkeys, and load secrets at runtime within the process. Everything else is dangerous.

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.

Exactly. There are tools that allow debugging production environments without having to have the credentials on your disk.

I recommend Envie: https://github.com/ilmari-h/envie

It's more convenient than having a bunch of .env.prod, .env.staging files laying around, not to mention more secure.