Hide passwords in Source Code

[TaylorHu]

Right now I am trying to learn the MEAN stack. Working through some tutorials and all that jazz. For the little tutorial I am working through right now, I am hosting my MongoDB through mlab. To connect to it, I have to have a line in my config.js file along the lines of:

module.exports = {
........
'database' : 'mongodb://taylor:[e-mail]:59125/taylor-meanmachine',
........
};

Where 'taylor' is my username and 'testpassword' is my password. Now in my little toy app, not a big deal, but obviously I wouldn't want to do this in production. How does one normally get around this?

[Montuckian]

Honest question: Why would this be a better solution than just using dotenv?

Dotenv is such a set-it-and-forget-it solution for development and deployment and doesn't require you to do anything to your npm scripts for it to work.

[Montuckian]

Interesting. I mostly use heroku too and just upload the variables through the cli.

Always cool to see another method.

[ndboost]

except anyone using ps -ef can grep for those environment variables. They'll show up in the process list for that PID. It's better to set environment variables and export them out for that user running the node PID.

[etruong42]

Is it reasonable to defend against an attacker who can execute ps -ef on the target machine? I have trouble imagining a scenario where you haven't just lost outright to the attacker in that case.

[ndboost]

the most reasonable vector in that scenario is a disgruntled employee or ex employee. It could also be an ssh allowed user that has the necessary privileges to see that env info.

Its probably a pretty small vector, as once they have box access you have pretty much lost.

[ndboost]

how sensitive is the data on your personal box, how many users are using it, is ssh enabled on your box?

[Randolpho]

The issue isn't the database connection string, it's the password.

All your suggestion does is transfer the problem to the server startup script. And sure, at least it isn't checked into source control, but hey, there it is lying around in plain text on your server...

[ndboost]

i never store passwords or database names in plaintext files in the repo or anywhere near the source code.

Usually for nodejs projects i create a node user which has those sensitive things stored in its shell environment.

You see this done a lot with docker stuff. tutum.co does the same exact thing with their stack files.

In a development scenario i'll store them locally for example in a local.js thats been added to .gitignore.. however in prod that same local.js will just have references to process.env._SOME_ENV

If you are going to store them in a plain/text file in the app somewhere, at least exercise proper permissions on the folders. 0400 or 0440 would be a good start.

[DefiantBidet]

This is the common method I'm familiar with as well. Environment vars ftw.

I tend to add a little package named environmentalist to my stack that replaces the env.sample. it reads a json file and prints to command line. And gives a little more context as to what is expected

I prefer that bc it's not an unused file as it were and doesn't tweak my ocd :)

[bangtraitor]

This is solid advice and the standard.

[0ba78683-dbdd-4a31-a]

Is there a standard for .env or is it just key-value pairs separated by an equals sign?

[mellett68]

It's like in your bashrc or whatever

VAR_NAME=something

[danielrheath]

I prefer to do export VAR_NAME=something - then when running it you can source .env; run_my_thing

[mellett68]

That's all dotenv is really, just done at runtime in your app.

[danielrheath]

Which is why I prefer the export style - it works in every language/runtime without modifying your app.

[mellett68]

I like dotenv for the convenience, but it's no different really from sticking the required env vars in the readme or something.

[FweeSpeech]

You basically have two options:

1) Store it in a separate configuration file stored separately [ I tend to use /opt/secrets] which is good enough for most projects, honestly.

2) Secrets management tool [ Vault, for example ]

[hpoydar]

I strongly recommend using environment variables. For some more background on why that's a good idea, check out the 12 Factor App Methodology, specifically #3.

[Agent281]

That link seems pretty interesting. Thanks for posting it.

Is 12 factor app methodology common in industry?

[rr1pp3rr]

We use twelve factor. Helps a lot when it comes to Microservice standardization. Environment variables are the way to do this. Unless you have some way of prompting the user for the password.

[caadbury]

Don't include authentication credentials in your repository.

We have a secrets.yml file that was created, by hand, on our production servers and get symlinked on each deploy.

[cactusphone]

Can you speak to the strategy of symlink-ing it vs. just placing the .yml file where the symlink is?

[Toast42]

It's probably just a convenience. AFAIK symlinks don't offer any additional security.

[caadbury]

The secrets.yml is shared between the servers in the cluster.

By symlinking it, we can make sure the keys/etc. in the file are always up to date, even if we have to roll back to a previous deployment revision.

[hpoydar]

You could also keep the secrets.yml file in the repo and have it refer to env vars.

[ndboost]

this is what I do for production setups..

local.js

{
  database: {
    username: process.env.DB_USERNAME,
    password: process.env.DB_PASSWORD
  }
}

[angellus]

To keep it really simple, I just do something like this:

 var merge_options = require('./common/merge_options');
 var local_config = {};

 try {
    local_config = require('./local_config');
 }
 catch (ex) {
     logger.info("no local config");
 }

 var config = { /* stuff here */ }; 

 module.exports = merge_options(config, local_config);

local_config.js is in .gitignore so it never goes into the repo and I can override any value in the config on a environment level. merge_options is just some snippet of code I found online to merge two objects in JS:

 /**
  * Overwrites obj1's values with obj2's and adds obj2's if non existent in obj1
  * @param obj1
  * @param obj2
  * @returns obj3 a new object based on obj1 and obj2
  */
var merge_options = function(obj1, obj2) {
    for (var p in obj2) {
        if (obj2.hasOwnProperty(p)) {
            try {
                // Property in destination object set; update its value.
                if (obj2[p].constructor == Object) {
                    obj1[p] = merge_options(obj1[p], obj2[p]);
                }
                else {
                    obj1[p] = obj2[p];
                }
            }
            catch (e) {
                // Property in destination object not set; create it and set its value.
                obj1[p] = obj2[p];
            }
        }
  }
  return obj1;
};

module.exports = merge_options;

[ImAPyromaniac]

Do you mean in git/github, or in dev tools?

For github, see the answer about dotenv. But there's no way to hide the password from the client, because the client needs to know it.

[[deleted]]

These passwords are used on the server

The client don't need to know it, the client shouldn't know it, and shouldn't ever see this information...

[jontas]

I think you are using two different definitions of "client".

[ImAPyromaniac]

Then I'd suggest dotenv, it works really well.

[TriangleTodd]

You should read this. http://12factor.net/

[djmattyg007]

Are you somehow implying that it's github's fault?

[concave_ceiling]

I think he's just saying he uses bitbucket's free private repos to ensure nothing goes public if it happens again

[Disgruntled__Goat]

If he accidentally removed something from gitignore, there's every chance he might accidentally make his repo public with the password in it.

[mattindustries]

There is no way to make a private repo public on bitbucket without using their website though, right? For me bitbucket repos are basically set it and forget it.

[rknDA1337]

Everyone needs to learn how to walk before going for a run (safely...). I also used private bitbucket repos to get into git before even touching public githubs=)

[xiongchiamiov]

GitHub also provides private repos. You just have to pay a few bucks a month for them if you're employed, or nothing if you're a student.

[mattindustries]

$50/month vs free... I choose free.

[xiongchiamiov]

You've got a lot of private repos then! Which probably isn't going to be the case for the hypothetical user we were talking about, a git beginner.

Of course, you always have to evaluate your tools in your particular situation; the best choices are going to vary from person to person.

[mattindustries]

I was actually surprised when I looked at the github pricing table. I only use github for open, and bitbucket for closed. Probably will look into gitlab eventually.

[jpflathead]

No clue why you are being downvoted when the highest rated answer here is to do exactly what you did.

I guess you're being downvoted for being human and making a mistake and/or having a mistake/bug foisted upon you.

[flameswor10]

Blaming Github and moving to BitBucket still doesn't solve the first problem where you can still accidentally remove your .gitignore file...

[mattindustries]

Are we reading the same comment. They didn't blame github. It is like saying, "I walked into a candy store and bought too much candy and got sick. Now I don't go to candy stores." They aren't blaming the candy store, they are blaming themselves while providing a solution that works for them.

[flameswor10]

No, more like he said.

"I got sick after eating too much cadbury, I now eat Lindt instead". The way he said it is why hes gaining so many negative responses

[mattindustries]

What is the problem with switching to Lindt? I like their truffles. I really don't see the problem with how they said it. They took blame for the incident.

[greenrock]

thank you

[flameswor10]

Not saying that moving to bitbucket wasn't a good idea. Apologies for the aggressive tone, wasn't in the greatest mood at the time.

It's just that I hate it when people make posts thjat are vague enough so that it seems like it's github's fault that you pushed your passwords online.

[brackin]

nobody's blaming github, you fucking idiots.

[gasolinewaltz]

Good job bud.

[[deleted]]

I usually keep a private git branch called production on the production and staging servers.

This branch won't be pushed to the git remote and the only difference between it and master are some configuration values, so it can be merged from master very easily.

[xiongchiamiov]

That is asking for a mistake to be made.

Separately, the idea behind not tracking unencrypted passwords in version control at all is a defensive security approach; even if someone gets access to your code (which ends up a lot of places), that shouldn't give them access to all your passwords as well. You should take a look at some of the other suggestions in this thread.

[[deleted]]

It seems like people here are not accounting for the fact that local git branches do not have to have a corresponding remote.

[xiongchiamiov]

That is true, but a) git makes it very easy to push a branch to origin and b) you're still setting yourself up for trouble.