4 Things We Learned About Security From Pokemon Go

As we’ve discussed here before, we like Pokémon Go a lot. It’s given us new perspective on similar projects we’ve built before. While the technology underlying the game–GPS, the Unity game engine, augmented reality, and so on–is sophisticated, the pieces have been assembled in a way familiar to many app developers. It’s no surprise that communities and tools sprang up quickly, finding different ways to monitor and interact with the data. (And, in many cases, to cheat.)

Even Niantic’s most optimistic estimates for adoption did not anticipate the sheer popularity of the game and the traffic they ended up dealing with, especially in its first few weeks. For any of us doing work on apps that work with servers, there are some clear lessons to incorporate about security and scaling! We investigated by building a few proof-of-concept iterations of a tool for our own use; here are four things we learned to consider.

1. Start with a solid stack

There are plenty of known best practices to build into the foundation of your API. Use TLS to secure your communication, use a lightweight data format (and gzip it!) to reduce demand on mobile bandwidth, require renewable tokens to verify a user’s identity, and consider outsourcing your identity infrastructure to a trusted provider, the way Niantic did via Google and Pokémon Trainer Club accounts. All of this paved the road that allowed Pokémon Go to become the highest-grossing app in the App Store for months.

2. Anticipate what robots might do with your stuff

An app is one interface to a server, but if you do use a common and well-decoupled stack, it’s likely that someone can build a more ruthlessly efficient automatic interface: a bot. Are you putting business logic–like “you can only catch this Pikachu with a skillful toss,” or “this ad pays out if a mouse clicks on it”–in your client? With the right incentives, a bot can and will circumvent that logic to meet the goals more efficiently. Security analysts call this threat modeling, but it’s not from the usual standpoint of protecting your server’s data. In cases like this, it’s about protecting the server’s behavior.

3. Think about where your users come from–or don’t

For weeks after launch, much of the traffic that slowed down Niantic’s servers came not from individual humans, but from server farms. It was a borderline DDOS attack out of enthusiasm rather than antagonism. When we experimented with prototype Pokémon maps, we followed a practice that is increasingly industry-standard: we tossed them up on virtual servers belonging to Amazon Web Services. It’s a cheap deployment solution–and it should be easy to see, in hindsight, that nobody with an AWS IP address is a real Pokémon trainer. Niantic blocked those IPs en masse eventually, and we’re guessing that the next time they launch a game, they’ll be pre-blacklisted for convenience. This kind of filtering is hardly a perfect shield, but it’s a start, and simple to implement pre-launch.

4. Keep watching, keep learning

Even for bots and hacks that avoided getting IP-blocked, Niantic developed patterns over time to identify accounts that didn’t act like real people. Early on, quickly moving tremendous distances to scan for rare finds was enough to get your accounts banned, as was making too many API requests in a short time–but confining an account’s activity to a small geographical area helped avoid suspicion. After a few weeks, however, it became clear that there were new kinds of pattern recognition in play. Most humans stop moving for at least a few hours a night, for instance; accounts that never seemed to stop walking got flagged and shut down, even if they were just looking around.

Building a secure and stable API isn’t easy, and building a smart one is harder still. We’re glad that the attention on this particular game has provided learning opportunities like this for our entire industry. The launch of Pokémon Go has been a boon not just to gamers (and to those of us who could stand some more fresh air), but to anyone who could use an object lesson about the perils of unprecedented success.

0