3 Things That Make Encryption Easier

Almost everyone (especially in ops) knows they should be better about encrypting secret data. And yet most organizations have at least a few passwords and secret keys checked into Git somewhere.

The ideal solution would be for everyone at your company to use PGP all the time, but that is a huge pain. Encryption tools are annoying to use, and a significant time investment is required to learn to use them correctly. And if security is hard, people will always find a way to avoid it.

In the last few months, I’ve adopted 3 new technologies that make secure storage and exchange of secret information at least bearable.

1: Blackbox

StackExchange’s blackbox tool makes it easy to store encrypted data in a Git repository. First you need to import into your personal keyring all the PGP keys you want to grant access to. Then you initialize the blackbox directory structure:


dan@george:/tmp/secrets$ blackbox_initialize
Enable blackbox for this git repo? (yes/no) yes
VCS_TYPE: git
NEXT STEP: You need to manually check these in:
git commit -m'INITIALIZE BLACKBOX' keyrings /private/tmp/secrets/.gitignore
dan@george:/tmp/secrets$ git commit -m'INITIALIZE BLACKBOX' keyrings /private/tmp/secrets/.gitignore
[master 695d29a] INITIALIZE BLACKBOX
2 files changed, 3 insertions(+)
create mode 100644 .gitignore
create mode 100644 keyrings/live/blackbox-files.txt

view raw

gistfile1.txt

hosted with ❤ by GitHub

Once you’ve initialized blackbox, you can start adding administrators, which are keys that will be granted access to the secret data in the repository:


dan@george:/tmp/secrets$ blackbox_addadmin dan@danslimmon.com
gpg: /private/tmp/secrets/keyrings/live/trustdb.gpg: trustdb created
gpg: key A9FD8CCF: public key "Dan Slimmon " imported
gpg: Total number processed: 1
gpg: imported: 1 (RSA: 1)
NEXT STEP: You need to manually check these in:
git commit -m'NEW ADMIN: dan@danslimmon.com' keyrings/live/pubring.gpg keyrings/live/trustdb.gpg keyrings/live/blackbox-admins.txt
dan@george:/tmp/secrets$ git commit -m'NEW ADMIN: dan@danslimmon.com' keyrings/live/pubring.gpg keyrings/live/trustdb.gpg keyrings/live/blackbox-admins.txt
[master (root-commit) 94108f6] NEW ADMIN: dan@danslimmon.com
3 files changed, 2 insertions(+)
create mode 100644 keyrings/live/blackbox-admins.txt
create mode 100644 keyrings/live/pubring.gpg
create mode 100644 keyrings/live/trustdb.gpg

view raw

gistfile1.txt

hosted with ❤ by GitHub

Now you can start adding secrets securely:


dan@george:/tmp/secrets$ echo "nuclear launch code: SashaMalia44" > launchcode.txt
dan@george:/tmp/secrets$ blackbox_register_new_file launchcode.txt
========== PLAINFILE launchcode.txt
========== ENCRYPTED launchcode.txt.gpg
========== Importing keychain: START
gpg: Total number processed: 1
gpg: unchanged: 1
========== Importing keychain: DONE
========== Encrypting: launchcode.txt
========== Encrypting: DONE
========== Adding file to list.
========== CREATED: launchcode.txt.gpg
========== UPDATING REPO:
NOTE: "already tracked!" messages are safe to ignore.
[master 2a5eb65] registered in blackbox: launchcode.txt
2 files changed, 1 insertion(+)
create mode 100644 launchcode.txt.gpg
========== UPDATING VCS: DONE
Local repo updated. Please push when ready.
git push

view raw

gistfile1.txt

hosted with ❤ by GitHub

I really like how this tool gives my team a distributed, version-controlled repository of secret information. We can even give other teams access to the repository without worrying about exposing secrets!

My team uses this tool for shared passwords and SSL private keys, and it works great. Check it out.

2: Salt

At my company, we use Salt for config management. Like most config management systems, Salt lets you decouple the values in a config file from the file itself. You make a template of the config file that will appear on the node, and you put the values in a pillar (equivalent to a Chef databag, or a Puppet… whatever it’s called in Puppet).

So instead of storing a config file like this:


[myapp]
username = app_user
password = hunter2

view raw

blah.ini

hosted with ❤ by GitHub

You store a template like this:


[myapp]
username = {{ pillar['myapp']['username'] }}
password = {{ pillar['myapp']['password'] }}

view raw

blah.ini

hosted with ❤ by GitHub

and a pillar (which is just a YAML file) like this:


myapp:
username: app_user
password: hunter2

view raw

pillar.yaml

hosted with ❤ by GitHub

Now suppose you don’t want to commit that super-secure password directly to your Salt repository. Instead, you can create a PGP keypair, and give the private key to your Salt server. Then you can encrypt the password with that key. Your pillar will now look like this:


#!yaml|gpg
myapp:
username: app_user
password: |
—–BEGIN PGP MESSAGE—–
—–END PGP MESSAGE—–

view raw

pillar.yaml

hosted with ❤ by GitHub

When processing your template on the target node, Salt will seamlessly decrypt the password for you.

I love that I can give non-admins access to our Salt repo, and let them submit pull requests, without worrying about leaking passwords. To learn more about this Salt functionality, you can read the documentation for salt.renderers.gpg.

3: SecretShare

Salt’s GPG renderer and blackbox are great ways to store shared secret data, but what about transmitting secrets to particular people? In most organizations, when passwords and such need to be transmitted from employee to employee, insecure methods are used. Email, chat, and Google docs are very common media for transmitting secrets. They’re all saved indefinitely, meaning that an attacker who gains access to your account can gain access to all the secret info you’ve ever sent or received.

To make transmitting secrets as easy and secure as possible, my teammate Alex created secretshare. It lets you transmit arbitrary secret data to others in your organization, and it has immense advantages over other systems:

  • Secrets are never transmitted or stored in the clear, so a snooper can’t even read them if they manage to compromise the Amazon S3 bucket in which they’re stored.
  • Secrets are deleted from S3 after 24-48 hours, so a snooper can’t go back through the recipient’s or sender’s communication history later and retrieve them.
  • Secrets are encrypted with a one-time-use key, so a snooper can’t use the key from one secret to steal another.
  • Users don’t need Amazon AWS credentials, so a snooper can’t steal those credentials from a user.

Right now, secretshare only exists as a command-line utility, but we’re very close to having a web UI as well, which will make it even easier for non-technical people to use.

 

Security’s worst enemy is bad UX. It’s critical to make the most secure path also the easiest path. That’s what these three solutions aim to do, and they’ve made me feel much more comfortable with the security of secret data at my company. I hope they can do the same for you.