Kenneth Van Wyk: We need more secure mobile devices

30.04.2012
When you combine the words "mobile device" and "security," you get an oxymoron. That's the state of security in the mobile world, and it's been that way since day one.

That has to change. and are increasingly doing heavy lifting in the corporate world, and are ever more likely to be repositories of sensitive data. But where do we start in making them more secure?

For now, forget about malware and sophisticated hacking. We first need to close the most gaping hole of all for mobile devices, one that every expert I have talked to over the years has agreed on: If a bad guy gets physical access to a mobile device, all bets are off. A few months ago, the folks at the OWASP Mobile Security Project backed up this assessment. They did a threat modeling exercise of mobile devices and determined that two of the most glaring issues are the loss or theft of the device and insecure communications.

A basic problem is that anyone who gets his hands on someone else's smartphone can access the user's login credentials with ridiculous ease. Mobile apps contribute to this problem. I myself have realized that some of the mobile apps that I use store login credentials and other sensitive data where they shouldn't be, and in the last month or so, I've read about numerous cases of such iOS app weaknesses. Using nothing more than a USB cable, an attacker can in many cases get to login and/or session credentials for many high-profile apps, on both iOS and Android platforms.

That's unacceptable, and we've got to demand better from our app vendors.

For starters, mobile app developers must keep in mind when writing their software that devices can easily be lost or stolen -- and recognize that a lost device shouldn't be a free ticket to valuable data. Most modern mobile platforms provide mechanisms for reasonably protecting things like user login credentials. These mechanisms are generally called keychains. Current versions of both Android and iOS have keychain APIs that app developers can and should be using. While not perfect, they do provide significant protection over simply storing usernames and passwords -- even when hashed -- in plaintext files (e.g., plist or properties files).