Push Topics: Security
Posted by Dave
Note: This post is part of a series on the Deacon Blog that will address topics in implementing Push Notification systems. Naturally, this coverage is oriented toward the Deacon Project, but the topics and issues discussed are often widely applicable.
"Software security" - it's been a hot topic in the mobile phone world (or at least my feed reader) lately, what with multiple iPad and iPhone related security snafus at AT&T, and the release of the first major-label security software for Android phones by Norton/Symantec. With lots at stake in the mobile world - sensitive little things like GPS locations, contact lists and phone records - security should be a consideration in any mobile computing endeavor. Push notifications are certainly no exception.
Introduction
Bass, Clements and Kazman define a system's security as it's "ability to resist unauthorized usage while still providing its services to legitimate users." [1] We can decompose this requirement into two equally-important areas: determining which users are "legitimate", and restricting access to only those users. In push notification systems (and those based on Meteor in particular), there are also two types of users: push subscribers (those that receive notifications) and channel controllers (those that send notifications). Last in the rundown of areas to consider comes data transport: push notifications can traverse untrusted networks as they are generated, sent and received.
But before we dive into the security mechanisms that can be used with Deacon and Meteor, there's something important to keep in mind. For efficiency's sake, remember that push notifications should be as small as possible to minimize the load on the server. This is Google's advice when using Android's C2DM system; a notification's payload should only contain a "tickler" for the receiving app (such as an ID number or URL), which should then handle subsequent retrievals or processing after it receives the push. To enforce this behavior, Google limits C2DM payloads to 1024 Bytes - no such limit exists in Deacon, but it's still a good idea to follow the "tickler" approach.
So what can be done to secure push notification systems? It boils down to three relatively-simple practices: don't accept subscriptions from unauthorized users, use secure connections for channel controllers, and don't send data payloads that require secure transport. We'll take a look at all three after the jump...