The week we talk secrets.

2:02 Every company has lots of secrets. We’re going to talk about how we keep our secrets secure. We aren’t talking about secrets like our plans to take over the world, but things like social security numbers, passwords for hosting services, stripe information, etc.

3:08 There are a lot of things that we don’t store, like our user’s credit card numbers. But there are many things that need to be kept secure, like our passwords for logging into web services. That’s sensitive information. You can’t have our AWS password. That would be bad news!

So how do we keep those passwords safe?

Two-Factor Authentication

4:06 Tim carries around a dongle with him that stores a token that has to be used in addition to his password. So to login to AWS, not only would you have to know the password, you also have to have the dongle.

5:38 So that’s one way to do two-factor auth. You could also use Google Authenticator App on your phone. Using two-factor auth can be a pain in the butt, but if it’s hard for you, it’s hard or even impossible for someone else.

1Password’s Group Vault

7:24 We started off using Dropbox to share our encrypted passwords.

This is actually one of the ways that Sony was hacked. They had passwords in a folder called Passwords. We’ve been in tech for years, and we still used passwords in plain text. When we met up in Tampa, we decided to change all our passwords, and share any new passwords in a shared 1Password vault.

The value of the shared vault is that we all have access to it, and it’s easy to save a new password to our vault from any web browser.

10:28 The 1Password vault stays in our shared Dropbox folder. Even if someone gained access to our Dropbox folder, the vault is still encrypted. The vault file can’t be accessed without a master password.

11:21 We do follow all the normal wisdom about passwords; different passwords for every service, super long passwords, etc.

11:35 We store a hashed version of our user’s passwords, and we use a salt (added characters for additional security). We don’t store a plain text version of the password.

13:10 Our secrets file doesn’t get stored on Github. Included in this file are the logins to our AWS database.

14:21 When we launch a new server, a bunch of info gets pulled from git, but the passwords we need are put into place by a different server. The secrets themselves aren’t stored in git or on the developer workstations. They belong to a file that are separate from our codebase.

15:14 Our secrets are only as secure as our computers, but there is some sense of physical security.

16:28 Because most of our secrets are stored inside the 1Password vault, a thief would have to steal one of our computers, log into the computer, log into 1Password, and do it before we could change the passwords from a different computer. So we’re kind of backups to each other.

It’s like when you lose your wallet; you’ll just wipe everything. We’d do the same for our passwords, if we felt the need.

17:52 Multi-factor Auth: you can either have the dongles, or use your phone. For example, everytime Alex logs into Github, Github will send a secret code to his phone. Anytime we can use multi-factor auth, we do.

Deployment Keys, and a Quick Overview of IAM

18:54 Github allows you to create deployment keys; they act the same way as SSH keys, but are made per-service. Deployment keys are made for a one-time use.

CodePen is made up of a bunch of different services, so a deployment key would only allow access to a single one. So this would silo a hacker from being able to access everything.

How Can We Get Better at Security?

23:02 We don’t just want to share what we’re doing well, we also want to talk about what things we could improve. We recently looked at an app called Buffer that was in the news because of how they were hacked. Luckily, Buffer is a very open company, and they shared what happened so we could learn from it.

What we learned:

  1. We have access to some of our user’s Github accounts. We do limit the amount of access to only being able to read gists, which helps prevent anyone hacking Github accounts with our access.
  2. We should be encrypting Github access tokens. We are taking steps to make sure that happens.
  3. We should be keeping inventory of our “secrets”.

The Future of Security at CodePen

26:44 One of our new year’s resolution is to have a monthly “Infrastructure Day”. Each month, we’re going to get together and talk about what services could possibly be hacked, how we might be exposing our secrets, and what we could do to keep that from happening.

28:08 We’ve been looking at implementing a browser certificate that we could assign to ourselves. This is just a signed certificate that our browser would hold onto, and transmit when it encountered a specific URL. Only people that hold the certificate could hit that URL, and we would set that up for the administrative paths on CodePen.

30:16 HTTPS everywhere has been gaining traction lately. The problem is that it’s easy for any Pen on CodePen to link to insecure external content, which would cause the browser to throw a pretty nasty looking warning. It could definitely break a lot of Pens, and we don’t want to do that. It’s something we’re going to look into more.

“Security is a work in progress. You’ll never get to check it off as “done”. You’ll be revisiting this for as long as you’re working in tech; keeping track of your secrets.” – Alex

Show Links:

Thanks for listening!

If you’re enjoying this show, please take a minute to leave us a review in iTunes. We really appreciate it, and thanks to everyone who has already left a review! (We read all of them)

If you’re looking for a job, or if your company needs an awesome developer, check out CodePen Jobs!