Push Topics: Security
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...
Unauthorized Subscriptions
With Deacon and Meteor, this aspect of push notification security is the toughest nut to crack - but it's not that bad. The Meteor web server doesn't provide any means for subscribers to list the channels on a particular server, and while this doesn't prevent dictionary attacks by unauthorized subscribers, there's plenty that can be done to cut down the possibility and usefulness of such attacks. As we'll cover in the "Data Transport" section, transmitting data payloads that are meaningless outside the context of your receiving-end app is possibly the best way to dis-incentivize unauthorized subscriptions. Another approach to resist dictionary attacks is one-way cryptographic hashing of channel names at each end of the link. This would be especially useful if per-user channels are created based on a subscriber's username or e-mail address.
Finally, if you're really concerned about resisting brute-force attempts at unauthorized subscriptions (to access your obfuscated-name channels with otherwise-meaningless data, right?) then it's possible to configure most firewalls to rate- and quantity-limit inbound connections. While this doesn't theoretically rule out such attacks, it does make them computationally infeasible.
Secure Connections for Controllers
In order to send push notifications in a Deacon/Meteor-powered system, TCP socket connections are made from a channel controller to the controller interface of the Meteor server. While this is done over a standard port using an unsecured plain-text protocol, it's phenomenally easy to lock it down tighter than a drum and prevent anyone from sending unauthorized push notifications using your system: just tunnel this controller connection through SSH. You'll inherit the myriad ways SSH offers to lock down access, including public-key cryptography, fine-grained control over authentication methods, and IP black/white-lists.
Data Transport
Now that we've got the sources and destinations of your push notifications secured, it's time to consider the notifications themselves - and they're the easiest piece of the push security puzzle. Your push notifications - and their payloads, containing your data - will traverse plenty of insecure networks between the Meteor server and your Deacon client, and they'll do so unencrypted. The response, then, is simple: don't send sensitive data as part of your notification payloads! Instead, send a key, ID number, token or other "tickler" from your channel controller to your Android (or Java) app, which can then use a secured transport mechanism (https comes to mind) to retrieve the real user content.
If the tickler you want to send is sensitive - such as an account number or other meaningful data - consider using a one-way cryptographic hash that the client can pass back to the server as part of a corresponding secure transaction.
Conclusion
Even though the Meteor server and Deacon client are built on insecure protocols and simple interactions, it's not difficult to secure sensitive data that's passed to push-enabled apps. Importantly, these security measures don't cause any degradation of Deacon's performance, or negatively affect network bandwidth or battery life. The principles we've discussed here can be applied to just about any push notification system, but we like to think they're a pretty good reason to try out Deacon. Of course, if you see holes in what we've described, or have other ideas on how systems like these can be secured, don't hesitate to speak up in the comments or on the Deacon Mailing List...
[Padlock graphic: Wikimedia Commons, public domain]
[Surveillance camera image: Wikimedia Commons, GNU FDL]
[Network earth graphic: Wikimedia Commons, GNU LGPL]
[Flying message graphic: Wikimedia Commons, CC-Attrib 3.0]
[1] Software Architecture in Practice by Len Bass, Paul Clements, Rick Kazman, 2003.
