Best practice for managing web service credentials for Node.JS?
Asked Answered
E

4

5

We're planning a secure Node.JS server, which uses several third-party web services. Each requires credentials that will need to be configured by the operations team.

Clearly they could simply put them in plain text in a configuration file.

Microsoft .NET seems to offer a better option with DPAPI (Data Protection API) - see Credential storage best practices. Is there a way to make this available through IISNode? Or is there any other option to secure such credentials within Node-JS configuration?

Ethanol answered 9/10, 2014 at 15:25 Comment(0)
E
4

There's an extensive discussion of several options here, including the two suggested by xShirase:

http://pmuellr.blogspot.co.uk/2014/09/keeping-secrets-secret.html

User-defined services solves the problem, but only for Cloud Foundry.

This blog http://encosia.com/using-nconf-and-azure-to-avoid-leaking-secrets-on-github/ points out that you can often set environment variables separately on servers, and suggests using nconf to read them and config files separately.

I still wonder if there are specials for IIS?

Ethanol answered 13/10, 2014 at 11:12 Comment(0)
T
2

There is 2 ways to do it securely :

First one is to use command line parameters when you launch your app.

These parameters are then found in process.argv

So, node myapp.js username password would give you :

process.argv[0]=node
process.argv[1]=/.../myapp.js (absolute path)
process.argv[2]=username 
process.argv[3]=password 

Second is to set the credentials as ENV variables. It is generally considered as the best practice as only you have access to these variables.

You would have to set the variables using the export command, than you'd access it in process.env

Topi answered 9/10, 2014 at 16:52 Comment(2)
Thanks for the response. But maybe I didn't make myself clear. This will be a web server - there's no 'app' that I launch. So both ENV variables and command line parameters will end up having to be in a script somewhere; using them doesn't give additional security. Or have I missed something?Ethanol
your node server will still have to be launched from somewhere, so you can set the env variables on the machine that runs the server, no?Topi
G
1

I currently had to do the exact same thing for my External API credentials. this is what i did

  • install node-config module
  • create a folder and file called config/config.js
  • here require(config) module
  • In local box it reads the configuation from local.json file
  • i have dummy values in local.json for api key and shared secret
  • on my QA environment i export two variables NODE_ENV="QA" and NODE_CONFIG_DIR="path to my configuation folder on qa server"
  • node-config module reads configuation from "path to your config folder / QA.json"
  • now i have real api key and credential in QA.json
  • here you can use an encryption to encrypt these values and put it back in QA.json
  • in your app get these config values and decrypt use it in your rest call

hope this helps.

so your config can live in the same container as node code.

refer to this for encryption and decryption http://lollyrock.com/articles/nodejs-encryption/

Gabe answered 6/2, 2015 at 17:37 Comment(1)
Looking back at this comment, I should add a warning that @Jagadeesh's solution doesn't appear to deal with the 'bootstrap' problem: we still need somewhere to hold the encryption key. It's an interesting technique, but doesn't solve the underlying problem.Ethanol
E
0

Current best practice seems now to be https://www.freecodecamp.org/news/how-to-use-node-environment-variables-with-a-dotenv-file-for-node-js-and-npm/

The dotenv/environment variable combination allows you to store secrets in a .env file in a root directory away from source code control for development and testing. But it also allows more secure solutions on a production server, where the secrets can be fed in as environment variables from an HSM (Hardware Security Module) or whatever.

Ethanol answered 22/12, 2023 at 13:35 Comment(0)

© 2022 - 2025 — McMap. All rights reserved.