Is your mobile app ready for legalized Wi-Fi sniffing?

Sure, we've all known about network sniffing for many years, right? We've also known that sniffing a network we don't own is illegal--or was illegal anyway. But now that a US Federal judge has ruled sniffing an open, public wireless network to be legal, it's a different game.

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.

I know the above list is an over simplification in many ways, but our consumers are not likely to easily forgive us for an "oops" when it comes to exposing their sensitive data to a coffee shop attacker.

Securing network data is just one of many things we need to do, of course. But it's a biggie. Building security into our apps is a lot like physical fitness in that way. We don't just go for a jog the day after New Year's Eve because we feel guilty about how much we consumed over the holidays. It's a lifestyle change. It's a discipline. We need to think about it all the time and live it.

In our upcoming Mobile App Sec Triathlon, Gunnar and I will cover these topics, of course -- right down to code examples of how to implement the above list. We hope to see plenty of mobile app devs there, and to engage in meaningful dialog about different ways of approaching this and many other issues regarding secure mobile apps.

Cheers,

Ken van Wyk