I have created a config.js file which stores all my database connection information. I am then requiring this in my db-connect.js. The config file is gitignored so it won't be committed. However, I was wondering if this is secure, or if any more can be done to secure this information?
Config.js simply looks like this at the moment:
var dbconfig = {
database: 'dbname',
username: 'dbusername',
password: 'dbpassword'
};
module.exports = dbconfig;
There are similar questions on here,but all just say to not commit the file - however, to me this still doesn't seem as secure as it could be?
There may not be a correct answer to this, Here are your options
Environment variables:
i have seen people prefer saving their config in environment variables either in their ~/.bashrc file temporary for a perticular process eg:
~/.bashrc
export DB_USER=username
export DB_PASS=password
temporary
DB_USER=username DB_PASS=password node ./app.js
have your config files separate from the project and require it from a absolute path eg:
var config = require('/<path>/<to>/config.js');
so this way you will ensure your application will never serve your config file as it is not part of web root directory.
encrypt your config file and decrypt it every time you application restarts and read it.
I have preferred 1 and 2 on most applications.
I would like to add one more suggestion since keeping the configuration secrets in a config file is definitely a security (and manageability) concern. You can use https://www.npmjs.com/package/masterkey to store the secrets in a secure place like Azure Key-Vault!
Related
As you may see, I have my db connection file and another "protected" file, where my credentials are, and this file is included in .gitignore. I import it and reach the data. Quite basic. Therefore my questions are:
Is this the right way to do it?
If not, how should I do it? Plus: how could I add extra security to my account,connection?
Let's suppose I have a private collection, that no one should see, how could I protect specially this collection? I mean, with a password or a two step verification let's say.
Current code:
const mongoose = require("mongoose");
const mongoCredentials = require("../protected/mongoCredential");
const URI = `mongodb+srv://${mongoCredentials.username}:${mongoCredential.password}
#firstcluster-eldi8.mongodb.net/culturapp?retryWrites=true&w=majority`;
mongoose.connect(URI, { useUnifiedTopology: true, useNewUrlParser: true })
.then(db => console.log("MongoDB is connected"))
.catch(err => console.log(">> ERROR: ",err));
module.exports = mongoose;
...I have my db connection file and another "protected" file, where my credentials are, and this file is included in .gitignore. I import it and reach the data..
The correct way to do it is to use envrironmental variables.
Use environmental variables
Environmental variables are set on the environment, i.e your local development machine or the remote production server.
Then, within your app, you read the environment variables and use them appropriately.
There's (at least) a couple reasons it's usually done like this:
The credentials don't exist in a file that can be read by someone viewing the repository contents. Someone cloning the repository doesn't need to know your database credentials.
The credentials are likely different between environments. You are likely using a different database on your local development machine and a different database in your remote production server.
Here's how you set environment variables (this is for Linux, other OS's might be different):
$ export MONGO_DB_USERNAME=foo
$ export MONGO_DB_PASSWORD=bar
and here's how you read them within Node.js:
console.log(process.env.MONGO_DB_USERNAME) // logs 'foo'
console.log(process.env.MONGO_DB_PASSWORD) // logs 'bar'
or pass variables to the process when starting up
Alternatively, you can pass variables when starting up the process like so:
$ MONGO_DB_USERNAME=foo MONGO_DB_PASSWORD=bar node app.js
However that's generally discouraged since you're most probably starting your process through the npm start script. Since package.json, where the npm start command is defined, is always committed to the repository it defeats the whole purpose of hiding the credentials.
Like you mentioned along lines, using environment variables is more like security through obfuscation.
I would try to have the credentials in a separate configuration file. With a bit of design, encrypt this file and store those keys in secure enclaves or TPMs.
Check this thread.
As you may see, I have my db connection file and another "protected" file, where my credentials are, and this file is included in .gitignore. I import it and reach the data. Quite basic. Therefore my questions are:
Is this the right way to do it?
If not, how should I do it? Plus: how could I add extra security to my account,connection?
Let's suppose I have a private collection, that no one should see, how could I protect specially this collection? I mean, with a password or a two step verification let's say.
Current code:
const mongoose = require("mongoose");
const mongoCredentials = require("../protected/mongoCredential");
const URI = `mongodb+srv://${mongoCredentials.username}:${mongoCredential.password}
#firstcluster-eldi8.mongodb.net/culturapp?retryWrites=true&w=majority`;
mongoose.connect(URI, { useUnifiedTopology: true, useNewUrlParser: true })
.then(db => console.log("MongoDB is connected"))
.catch(err => console.log(">> ERROR: ",err));
module.exports = mongoose;
...I have my db connection file and another "protected" file, where my credentials are, and this file is included in .gitignore. I import it and reach the data..
The correct way to do it is to use envrironmental variables.
Use environmental variables
Environmental variables are set on the environment, i.e your local development machine or the remote production server.
Then, within your app, you read the environment variables and use them appropriately.
There's (at least) a couple reasons it's usually done like this:
The credentials don't exist in a file that can be read by someone viewing the repository contents. Someone cloning the repository doesn't need to know your database credentials.
The credentials are likely different between environments. You are likely using a different database on your local development machine and a different database in your remote production server.
Here's how you set environment variables (this is for Linux, other OS's might be different):
$ export MONGO_DB_USERNAME=foo
$ export MONGO_DB_PASSWORD=bar
and here's how you read them within Node.js:
console.log(process.env.MONGO_DB_USERNAME) // logs 'foo'
console.log(process.env.MONGO_DB_PASSWORD) // logs 'bar'
or pass variables to the process when starting up
Alternatively, you can pass variables when starting up the process like so:
$ MONGO_DB_USERNAME=foo MONGO_DB_PASSWORD=bar node app.js
However that's generally discouraged since you're most probably starting your process through the npm start script. Since package.json, where the npm start command is defined, is always committed to the repository it defeats the whole purpose of hiding the credentials.
Like you mentioned along lines, using environment variables is more like security through obfuscation.
I would try to have the credentials in a separate configuration file. With a bit of design, encrypt this file and store those keys in secure enclaves or TPMs.
Check this thread.
I am using config files to store defaults and passwords/tokens/keys.
Defaults are no problem to be public.
Obviously I want passwords to remain secret.
I mean - not to push the to GitHub.
I thought about make a configs directory contains the following files:
common.js everybody can see. keys.js passwords/tokens/keys. Shouldn't be pushed to GitHub - using .gitignore file to prevent this. keys-placeholder.js should contain just placeholders so who clones the project should understand to create keys.js file and place his real passwords.
Is it a good practice? How do you hide passwords from pushing to GitHub and also make it comfortable to use when build the project for first time?
Personally, I use config for public app configuration/constants and .env file and dotenv package for secrets.
Then add .env in .gitignore.
So example project would be
config // app configuration/constants
- prod.json
- dev.json
- test.json
.env // secrets
src/
- models
- app.js
...
----- added -----
Why don't you put the config in the src dir?
A: Of course it's totally up to you where to put your config folder.
It's just a matter of preference.
What about staging config?
A: Like question#1, you can add staging.json under config.
If you don't provide any placeholder file for .env, how do I know which passwords should I fill in this file?
A: Typical .env file looks like below.
API_CREDENTIAL=your api credentials
DB_PASSWORD=your db password
How do you lazyload the prod/dev config files to the node app?
A: I don't see much benefit for lazyloading small json files.
If you're asking specific how to guide for config and dotenv library,
please refer to their Github repository.(config, dotenv)
I have a nodeJS application. In the .env file I have specified
AUTH_USERNAME=admin
AUTH_PASSWORD=password
I now want to add separate admin accounts for more users. What is the best/accepted way to attack this? I have tried searching on the topic but, understandably, it gets very complicated very quickly - can anyone give me a dummies guide for my possibilities here?
Thanks.
The solution in your case without changing approach where to store credentials is use separator in environment variables. Example with , as separator:
#.env file or environment variables values
AUTH_USERNAMES=admin,admin2
AUTH_PASSWORDS=password,password2
//your code
require('dotenv').config(); // for reading .env file or how do you use that
const adminsUsernames = process.env.AUTH_USERNAMES.split(',');
const adminsPasswords = process.env.AUTH_PASSWORDS.split(',');
Please, think about change .env file to database or config.json file. Maybe, this list will help you:
obviously, you received downvotes on your question, because of non-common approach where to store credentials. Common approach is store credentials at database.
according The Twelve Factors manifest environment variables are
used for configuration whole application.
.env is used for simplification setting environment variables during local development. In production DevOps setup env vars on the server.
Well, I've come with a problem. How can I store passwords, db url and important strings that should not go to my public version control?
I've come up with 3 solutions. The first works only on dev:
var config = require('./config');
var port = config.serverPort;
config.js
module.exports = {
'serverPort' : '8182'
}
The second one should work both on dev and prod. But the config.js file was added on the .gitignore file, so it won't be upload to the server. When the server tries to require config.js and can't find it, it will throw an error.
var config = require('./config');
var port = process.env.PORT || config.serverPort;
The third is to use only process.env variables, but this only works on production. And, if I'm testing on local machine, I may need to paste my secret strings and remember to remove it before sending to the public version control.
So, what should I do?
The common solution is to add a config.js.example file to version control (that contains empty/dummy values to document what's available).
Then you add config.js to .gitignore (or whatever suits your VCS).
To run your application you simply copy config.js.example to config.js and put in the proper values.
Of course the path to config.js can be taken from an environment variable to allow easily using different configs - but still, you wouldn't put the actual config files under version control (unless you have a separate private repo for config files etc)
It does make sense to always require a config file to exist. Even in development. While the default settings may be suitable, chances are good that many developers on your application want to configure things anyway or simply test things with non-default values.
The dotenv package can be used to load configuration and secrets from a .env file into process.env. For production, the .env file doesn't have to exist.
Example:
require('dotenv').config();
const oauth2 = require('simple-oauth2').create({
client: {
id: process.env.TWITTER_CONSUMER_KEY,
secret: process.env.TWITTER_CONSUMER_SECRET
}
});
.env file:
TWITTER_CONSUMER_KEY=bMm...
TWITTER_CONSUMER_SECRET=jQ39...
.gitignore:
.env
Here is my suggestion:
1. Using a mix of file and env variables
You can manage secret strings using a mix with config files and process.env variables.
You can do something like this:
var port = process.env.PORT || config.serverPort;
Since now, working with docker is the rule, you should try this one.
2. Using a Sample
You could add a config.json.example to your repo with an example of the variables you should define but here you will have to remember to change it when you deploy to production.
Just remember to add the real config.json to the .gitignore file.
This one is not my preferred but still an option.
There's a node package that handles this very similar to the Ruby On Rails approach with their credential system: schluessel
It lets you save your secrets in an encrypted vault file and stores the key separately. This vauft file can be checked into your version control system, as long as you keep your key file secret.
You can create vault files for different NODE_ENVs.
If you surrender the key either via a key file or via an environment variable,
you can access your credentials very easily from within your app.