CODEWITHSUNDEEP
node.jsencryptionsails.js
ACoder
ACoder

Reputation: 103

How do I securely store the connection string when using sails.js

I have a database connection string in config\adapters.js which looks like below. I don't want to leave the connection string in plain text. What is the best way to secure that info and the service can call and connect to the DB? 

module.exports.adapters = {

  // If you leave the adapter config unspecified 
  // in a model definition, 'default' will be used.
  'default': 'mssql',

    mssql: {
        connectionString: 'Driver={SQL Server Native Client 10.0};Server=foo.domain.com;Database=RODDY;Uid=jsmith;Pwd=nw0ow21',
        module: 'sails-mssql'
    }

};

Upvotes: 4

Views: 5689

Answers (3)

NDBoost
NDBoost

Reputation: 10634

All the other answers are great answers, here is another approach.

Set an environment variable called something like SQL_STRING..

This assumes you're on ubuntu..

#edit /etc/profile or ~/.profile
vim /etc/profile;
#add this line to it.
export SQL_STRING=<insert your sql string>

now in your config/local.js file add this for connectionString:

connectionString: process.env.SQL_STRING

this will load the connection string as the environment variable. This will do two things,

  1. you can now commit local.js to your repo if needed, and wherever you deploy the app it will inherit whatever the env variables are set to. This is great for things like development environments and such.

  2. Removes secure data from your application files so no one can peek into them, they'd have to do some digging to get the actual data.

I currently do this in production on a sailsjs app, i have a special sails user which has a ~/.profile with all of my MAILGUN, db, and other credential data defined as environment variables. this user is restricted from sudo, ssh access, and is locked down to have access to only one or two folders.

Effectively the only people who can see those environment variables are root, and that user.

Upvotes: 6

Chad
Chad

Reputation: 2289

If what you are wanting is to hide your adapter connection credentials from version control, sails.js allows you to define your adapter configuration in config/local.js, which, by default, is added to your .gitignore so would not be checked into git[1]. Check out the sails.js deployment guide for more information about using local.js[2]. As shown in the deployment guide, you would use the local.js like this:

// Local configuration
// 
// Included in the .gitignore by default,
// this is where you include configuration overrides for your local system
// or for a production deployment.
//
// For example, to use port 80 on the local machine, override the `port` config
module.exports = {
    port: 80,
    environment: 'production',
    adapters: {
        mssql: {
            connectionString: 'Driver={SQL Server Native Client 10.0};Server=foo.domain.com;Database=RODDY;Uid=jsmith;Pwd=nw0ow21'
        }
    }
}

This will not prevent people that have access to your server from gaining access to this information, though. If you are worried about that, then the advice that @SamT gave is great to follow.

Upvotes: 0

SamT
SamT

Reputation: 10610

The problem with obscuring the connection credentials is the fact that your app needs access to communicate with the database and ultimately needs to access it in clear text. There is a consensus among web application developers that it is OK to store it in your filesytsem. If an attacker can get access to your filesystem, your system has already been severely compromised.

Being a web app, it is inherently at risk for attack due to its exposure to the world. You can follow safe, security-conscious practices to help manage the risks:

  • Create a user account in your database with just the permissions it needs and nothing more. You should never used an over-privileged account (like root) for your app to talk to the db
  • Disable outside access to your database
  • Keep regular backups offsite (another server, I use an s3 bucket)
  • Use a firewall to block all ports except the ones it needs to access the outside world (usually http, https, ssh)
  • Disable FTP and all other protocols that send data in clear text
  • Use strong passwords for your human accounts and use long, randomly-generated passwords for accounts used by your web applications.

This list is non-exhaustive, there are way more things you can do, but this is a good starting point.

Upvotes: 2

Related Questions