7

Secrets should not be in source code and in version control because of two reasons:

  • External threat: An attacker can exploit a vulnerability to get access to files/source of your website/application. For example by exploiting directory traversal or arbitrary file download vulnerability. Such an attack should not lead to leaking of secrets.

  • Internal threat: A developer maliciously copying/distributing source code. Understandably, there needs to be a small subset of people who need to know these secrets, what we are trying to avoid here is to have the secrets visible to all developers in the organization who have access to the version control system.

Environment variables is one usual solution. However, if the build scripts are also versioned then we are just changing the location of secrets from source code to the respective hudson/jenkins/capistrano script.

What are the best practices to keep passwords out of source code?

Improve this question
1
  • 2
    Square uses a tool they (well, we) have open-sourced called keywhiz. Secrets are managed by a central service, and accessed through a FUSE filesystem. Only hosts that have been assigned to a particular secret can access it.
    – Stephen Touset
    Oct 21, 2015 at 21:33

2 Answers 2

Reset to default
5

I can think of a couple of options which may help.

1)Keep the config file on the live servers and have the build process copy it to the new deployment folder. As long as you restrict access to the live box, you get away from everyone having access.

2)Encrypt the passwords and have the decryption keys live on the server. anyone without access to the box can't decrypt the file.

3)Use RSA, give the server a private key and store the public key in the app database. The public key encrypts the password file, the app grabs the servers private key and uses that for decryption. This way, anyone can have the config file and anyone with access to the DB can create one. Only people with access to the certificate store on the server can access the decryption key. You can add signing if you want.

You can keep copies of the keys/passwords somewhere with restricted access in case you need to recover them.

Improve this answer
1
  • the RSA suggestion (suggestion #3) is a great idea! I wouldn't have thought of that, but that's certainly an interesting approach which seems secure.
    – Spencer D
    Oct 23, 2015 at 17:22
3

If you need to hide them, you can just move them in a separate file (a config file or something) that you can add to you .gitignore or equivalent. You can provide a second, non-hiden sample file that will show the user how to enter his own passwords or Keys.

Improve this answer
1
  • 1
    This is common practice in *nix hosts, especially for dealing with MySQL connections (--extra-defaults-file). If you are in a similar scenario, remember to set the file permissions accordingly (least privilege principle)
    – Purefan
    Oct 21, 2015 at 23:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .