Snapchat’s Unhappy New Year
As soon as Extra Into the Breach…
Lower than a month after the Target credit card breach another significant data theft is in the news. This week’s victim is Snapchat, the popular photo sharing social network. Gibson Security announced the weakness, with some solid technical analysis of the API’s problems. The New York Times has some good mainstream coverage, as do other news outlets.
The irony of this situation is that Snapchat’s brand promise was all about security and privacy. Ephemeral photos could capture a moment without permanently tarnishing one’s reputation. Regardless of how well they delivered on that core feature, poor custodianship of other customer data will leave many users wondering how well the app will deliver on privacy where it matters. One indiscretion may well permanently tarnish Snapchat’s reputation.
Why Does This Keep Happening?
One key quote from the New York Times article illustrates a problem common in API implementation:
In an email, one researcher said the data was not being encrypted or “hashed” to make it difficult for hackers to piece together. “They hadn’t even implemented rate limiting,” the research said.
Why is this common? I think there are two reasons. First, things like rate limiting aren’t perceived as adding value. They’re not something that gives your company an edge. So they’re not the first thing you’re going to implement, even if they do add value (security) to your application or service. Second, high traffic volume is a good problem to have. And with a solid DevOps team, there may be valid reasons to avoid throttling the overall service – for example you want to scale elastically to allow for the unfettered growth and popularity of your fledgling service, allowing you and your team to realize a billion dollar payout. That payout may be at risk, however, if you don’t secure your service, and ultimately that’s why you need rate limiting — to protect against dictionary attacks, DDoS, or other malicious use of your service.
The same goes for encrypting or hashing. Implementing these things takes time, and adds complexity to the logic tier. It can also make an app harder to debug, as developers can no longer talk directly to the DB tier of the application to make sense of what’s happening — additional tools are needed. And finally, depending on when the hashing or encryption is implemented, it could also break other pieces of the application — for example if the developers had decided that it was worth their time to do formatting checks on phone numbers to ensure that valid data was being persisted.
How to Prevent This?
This sort of thing is going to keep happening if the risk/cost of addressing it is perceived as being less than the cost to fix it. Fortunately there are steps that can be taken to help mitigate the risk without adding significant development cost. One such solution is to utilize a service gateway to handle API security. Rather than reinventing the wheel with DDoS protection, Content Attack Prevention policies, and other security features, a development organization can implement standard, proven tools to deliver the same functionality. As new threats need to be addressed, they can be added and managed centrally, avoiding the need to commit changes to multiple back-end services.
As for the encryption piece I mentioned earlier, Format-Preserving Encryption is a relatively new tool that protects data while allowing it to pass format consistency checks. This allows data at rest to be encrypted which limits the impact should an attacker make it through the first lines of defense, but it avoids the need to recode the logic tier to accommodate new data formats.
Securosis recently released a nice whitepaper that summarizes how API gateways can add security while enabling innovation. I also did a webinar with the authors in October the place we mentioned this subject. Keep tuned to this weblog as smartly – we’ll proceed to duvet these occasions and highest practices in API safety because the year unfolds.