Http request auth digest msg input?

General
1

Hi, need to use auth digest for a http request. But I'm only able to enter into the password field of the http request node settings, thus leaking into git (together with the password which is stored in a nearby config file).

How can auth digest be used with http securely through env.get as msg parameter in input to the node? Otherwise I have to manually add code for the digest mechanics in a separate step before the request.

2

Nevermind, password field supports env arg directly like ${PASS}, brilliant!

3

But also the values should be encrypted in the flows_creds.json, if you are using the projects feature the secret used to do the encryption should not be checked into git.

4

That's futile when the password to decrypt flows_creds.json is also in git right next flows_creds.json itself. Password to decrypt is stored in clear text in .config.projects.json. We never store any secrets in node red nor its secrets vault.

I could of course put .config.projects.json on git ignore? But what's the point, it only stores secrets that's entered in specially allocated fields. Our secrets are used many other places, like function nodes. And for that we need .env, not nr secrets storage?

5

Password to decrypt is stored in clear text in .config.projects.json. We never store any secrets in node red nor its secrets vault.

Using the Projects feature that value should not be checked in, you should be asked for it at the time you check out the project.

Now, if you are managing storing flows in Git yourself, then yes you have to manage that yourself.

There are also nodes to inject secrets into flows and store them in the credentials store.

e.g. node-red-contrib-credentials (node) - Node-RED

6

We could treat .config.projects.json essentially as an indirect env file yes. But when we already need env file for other purposes, it just adds on what we already got.

7

Sure, having support for additional nodes to do that work can be useful. If you want to go down that route. From my point of view, it'll just be more dependencies, more clutter in flows with additional nodes. All this to simply do the same as env.get("PASS") which is supported universally without extra nodes or libraries. I just don't see the benefit. Feels like a lot of effort to avoid very simple js.

8

Also worth noting a couple of things about environment variables:

  1. Environment variables are NOT A SECURITY FEATURE! Any compromise of the server also compromises any active environment variables.

  2. Now that Node-RED v5 baselines on node.js v22+, you can start node-red with a node.js parameter that will automatically read a .env file in the startup folder. Unlike trying to add an export before the node-red start command, this is fully cross-platform.

9

Been down this road before, any compromise of env is same as compromise of the config file. They live in the same space, so suffer exactly the same vulnerabilities.

Cool to hear native support of .env, currently using env.json file imported in settings.js.