It's almost impossible to have not heard of the massive Equifax data breach that was announced last week, but in short: the credit reporting agency was breached by hackers, who walked away with as many as 143 million Social Security numbers, names, and addresses. For Americans, this is nothing short of catastrophic.
First, off, it seems like there are a few things you can do. The New York Times piece has a few recommendations, as does a comprehensive Reddit thread—check out the sticked first post for some things you can do straightaway.
Maybe, some point in the future, we'll get a full postmortem of what allowed this intrusion to happen. Until then, let's think about how we can better protect our own applications from becoming victim to this increasingly-familiar story. It's important to note that I'm focusing primarily on single developers, or small teams, who aren't dedicated security experts—large corporations and those dedicated to systems security have wildly different, and more complex, things to worry about.
1. Store only what you need to
Do you really need to store customer credit card data from their one-off purchase? Do you really need to ask for their mother's maiden name during signup and keep that in your database? Do you really need their home address and the last 4 digits of their Social Security number?
The answer, in most cases, is probably not. Or, definitely not.
The absolute best way to protect yourself against an embarrassing breach of highly sensitive information is to simply refuse to store that information in the first place. In most cases, particularly if you're running something like a simple SaaS application, you shouldn't need much more than their username and their password—maybe a first name to help personalize their experience.
Recurring billing models require a bit more information, of course, but more on that in a minute.
I genuinely hope that this incident, for all its potential impact for pretty much every American with a credit card, finally resets our expectations of what information an application needs to know about its users, and what users are expected to cough up in exchange for a functioning account.
Choice is critical here—some applications require more data than others, but the less required fields, the better the experience for everyone. Any application we build should emphasize minimalist data collection. That reduces risk, and, if databases are breached, at least minimizes the loss.
2. Outsource what you can't adequately protect
Businesses rely on taking payments, and doing so online is no joke. Do you really want to dive into the 12 primary requirements and 220 sub-requirements to become compliant with PCI-DSS? That's the barrier you need to hit in order to protect yourself against massive fines and other civil action in the event your payment information database is breached. Chances are you don't have the time, effort, or expertise to take credit cards online properly.
Square has a nice round-up of potential consequences for not complying with PCI standards: up to $100,000/month in fines, costly forensic audits, and more.
This is why payment companies exist. Whether it's retail point of sale (POS) or online credit card processing, just about every business ends up relying on some credit card processing company to take on the bulk of the security
by subscribing to our newsletter.
