Let's put this into context a bit first. The Mobile Security Project over at OWASP started working a while back on a Top Ten Mobile Risks effort. They reckon the third biggest risk to mobile users is "insecure transport layer protection". (Number one on the list was insecure local storage, such as in the case of a lost or stolen device, and number two on the list was weak server side controls.)
Insecure transport layer protection is a kind way of saying that mobile developers often times don't adequately protect their apps' secrets while in transit. When we fail to encrypt things that matter -- e.g., authentication credentials, session tokens, device identifiers, user data, geolocation data -- we expose our users to what I like to refer to as a "coffee shop attack". Prior to that court ruling, the coffee shop attack was illegal. Of course, criminals weren't much deterred by that, but at least the victim might have some legal recourse if an attacker's action was itself illegal. No more. The gloves, as they say in ice hockey, are off.
Of course, those of us who understand the technologies involved wouldn't dream of using an open Wi-Fi without first encapsulating all of our network traffic inside a strong VPN tunnel (if at all).
Well, the average consumer can't even spell VPN, folks. Assuming our users will use a VPN is simply not adequate. So what does that mean for mobile app developers? How do we protect our consumers from (now legal) network sniffing?
For starters, we have to design and implement our apps under the assumption that our users will be using the apps in a hostile network environment, like an open Wi-Fi in a coffee shop. If your app can't withstand the scrutiny of running securely on an open Wi-Fi, you have no business using the word "secure" to describe it in any way.
That's all easy to say, of course, but how does it translate into Gunnar's "what do I do?" sort of action?
Here's some things to consider:
- Make an inventory of all the sensitive data in your app, from the low level (e.g., user authentication) stuff through the high level (e.g., user data).
- Make it a security requirement that all such sensitive data will be protected while at rest as well as while in transit, whenever possible.
- Ensure that all network connections where sensitive data is to pass are strongly encrypted (e.g., SSL, perhaps with certificate pinning or other strong certificate verification).
- Verify through code reviews that all sensitive data is encrypted in transit.
- Validate through dynamic validation testing that all sensitive data is in fact (not just in theory) encrypted in transit.