Keeping user data safe
[ ]Patrick Toomey has posted a document on some low-friction ways to reduce risk in your software projects. Those methods are based on his 5 years of experience in application security, many security issues and associated data disclosures are the result of technically unsophisticated attacks.
Password123!
There is near universal consensus among security professionals that passwords are one of the weakest links in the security chain. In many companies, employees have access to a tremendous number of services. As a result, any weakness in employee password hygiene can often lead to access to your user’s data. So, until we have a ubiquitous replacement for passwords, the risk remains.
The best strategy is to use randomly chosen passwords for each service you use. This helps protect against password reuse attacks. For example, by using unique passwords, you drastically reduce the risk of an account compromise from a random social media account from being used to access an Amazon AWS account containing your users’ data.
We can’t all be expected to remember hundreds of completely random passwords, and no one is suggesting you write them all down on a Post-it. Here’s where password managers come in.
Password managers like 1Password and LastPass can help you by:
- Creating longer and more random passwords
- Storing your passwords in a safe place
- Only requiring memorization of a single password to access your password manager
- Protecting against some types of phishing attacks
Many password managers also support shared password management. This can be incredibly useful in team settings, where you often need a way to access a shared service with a single account.
Enable two-factor authentication
Beyond strong passwords, keep an eye out for the option to enable two-factor authentication—and always enable it. It’s an extra layer of security designed to ensure that only you can access your account, even if someone knows your password.
U2F has traditionally required users to carry a hardware token in order to authenticate. And while hardware tokens provide the the strongest protection against attacks, a software-only implementation offers the vast majority of U2F’s benefits. That’s why GitHub released SoftU2F, a software U2F authenticator for Mac OS X.
Always enable two-factor authentication and add on U2F wherever possible. And if you run a GitHub organization, I’d recommend auditing and requiring 2FA to access any of your organization’s resources. Finally, make sure to download any provided recovery codes when you enable two factor authentication. This way, you won’t be locked out of your account if you ever lose access to your second-factor credential.
Keep secrets out of your code
Users can’t escape passwords and unfortunately neither can your code. A lot of code likely relies on interacting with other services that require authenticating using a token of some kind. Unlike user passwords, there isn’t a one-size-fits-all solution like password managers for storing and using these credentials securely in your code. As a result, they are prone to accidentally getting checked into repositories you push to GitHub.
Avoid development practices that rely on hard-coded credentials in your code. As noted above, there isn’t one solution for every situation. You’ll need to research alternative approaches that work well for your applications. But, if you see production credentials in you source code, even if in private repositories, it’s time to find a different approach. Once you have an established pattern, you can use tools like git-secrets to prevent commits that contains credentials in the first place.
Patch it up
Once your password and credential situation is in order, your next greatest risk is likely old software. Whether you’re running an outdated operating system, application framework, or utility library, your old software may be inviting data breaches.
That said, keeping all your software up to date is easier said than done. Try to automate what you can. In the case of application frameworks and libraries, services like Snyk and Gemnasium can be configured to automatically scan your repositories for outdated libraries and alert you when you need to update. GitHub recently added support for Snyk to GitHub Marketplace, further reducing the difficulty of installing and leveraging this kind of tooling across all of your projects.
Social coding for the win
GitHub popularized the pull request as a form of code review many years ago. A pull request provides an excellent opportunity for peers to have an in-depth review and discussion about proposed changes. Even if your team is short on security expertise, you can fend off many common security issues simply by fostering a culture that encourages rigorous code review.
A pull request should be an active dialog between all participants. Ask questions, challenge assumptions, and think of failure scenarios. Comments such as “Which users can access this data?”, “Let’s add a few tests to validate our assumptions here”, or “What will happen if this fails?” can go a long way toward minimizing security risk. Also, be wary of too many pull requests with a simple +1 review. The more complex the change, the more dialog you should see.
You can even leverage tooling to help with security analysis during code review. As your team grows, many of these tools can be extended to start looking for insecure coding patterns that are unique to your application:
- Static analysis tools can be used to help identity common insecure coding patterns
- Code Climate, Codacy, and other code quality tools can be seamlessly integrated into your pull request reviews.
Start a bug bounty program
Not every company has the resources to hire a dedicated full-time security team. Although you can leverage consultants to perform security reviews, these are point-in-time assessments. They’re valuable for in-depth review, but the reality is that your code evolves over time, and it pays to have as many sets of eyes on changes as possible. As a result, many companies, both large and small, have incorporated a “bug bounty” as an integral component in their security program.
Bug bounty programs offer individuals recognition and compensation for reporting bugs, especially those pertaining to security vulnerabilities and exploits. GitHub announced our bug bounty program nearly four years ago.
At that time, creating a bounty program had a relatively large barrier to entry. Since then, several services have emerged to make getting started a lot less complicated. For example, GitHub switched from a fully self-run program to using HackerOne, reducing some of the operational complexity.
If you start a bounty program, be prepared to see an uptick in bug reports that require triage and fixes—especially in the first few weeks. But rest assured, the benefits are measurable. You’ll gain access to a large pool of security professionals who can help identify bugs in your application and keep your users’ data safe.