The sky is falling! The sky is falling!
A lot of Chicken Littles are running around warning about the end of the world, brought about by the insecurity of mobile devices. There's a kernel of truth there, and I myself have bemoaned the state of mobile security. But there's also a good deal of exaggeration, born of (often vendor-fanned) fear, uncertainty and doubt. So, what's a user to do? Let's explore that a bit.
Broadly speaking, you have three choices: Avoid mobile devices altogether, carefully select the apps you install and use, or dive right in and hope for the best.
The one sure bet is to avoid smartphones and other modern mobile devices, but that doesn't sound like a lot of fun to me. There are a lot of really useful and ingenious apps out there, so you'd be robbing yourself of some great opportunities. Nonetheless, using a dumb phone may well be a reasonable course of action for some people. If all you seek from your mobile phone is the ability to send and receive voice calls, and perhaps an occasional text message, then you should find no shortage of free, carrier-subsidized dumb phones. You would indeed have fewer security worries, and more money in your pocket.
I just don't think that option is going to appeal to a lot of people. At the other extreme, diving in without regard for safety seems reckless. If you are hell-bent on maximizing the convenience of your smartphone, you'll be tempted by apps that help you manage your money, make payments, receive payments, transfer funds -- the list just keeps going. But what sort of person does that without thinking about the danger of exposing sensitive information on a device that is easy to steal or lose?
Personally, I've taken a middle road. I do have a smartphone, but I'm careful about the apps I install. What does it mean to be careful? Since I'm in the security field myself, it means that I vet the apps myself. But a lot of what I do can be done by just about anyone who knows a little bit about applications. Here are a couple of things you can try.
Static analysis. Maybe you didn't realize it, but you can poke around an app's sandbox and take a look at what's in there for yourself. All you need are your mobile device, a USB cable and free software such as iExplorer that lets you look at the files in each app on your device. (Note: These examples are primarily for Apple's iOS, but similar tools and methods can be used on Android as well.)
Connect your device to your computer (Mac or Windows) and use iExplorer to peek into its files. In each app's ~/Documents folder, you'll find files used by the app. Some common file extensions are .plist, .db, .xml and .txt. The first are "properties files," which are in an XML format and can be viewed using any text editor. Next, db files are database files -- likely SQLite3 files that can be viewed using sqlite3 on the command line. The other files are mostly text files as well. Drag them onto your main computer's desktop (or folder) and look at them one at a time. Look, for example, in the plist files for usernames, passwords and other application credentials. For SQLite files, try opening a command shell and typing "sqlite3 [filename.db]". Next, at the sqlite prompt, type ".tables" and you'll see whatever tables are present in the database. You can view those tables by typing ".dump [table_name]". Again, look for usernames, passwords, etc.
Look also in each app's ~/Library folder. In there, you'll find a Caches folder and a bunch of other stuff. Poke through there and look at the files. Again, look for properties files and database files, as well as image files. Depending on when you last ran the app, you may find some .jpg or .png files containing screenshots of your last session. View them all.
What you're looking for are some fundamental mistakes that developers commonly make. Storing usernames and passwords in properties files, database files, etc., is sloppy programming. (There are keychains that do a far better -- though not perfect -- job at securing that sort of data.)
If the app you're considering using makes such simple mistakes, you might want to avoid it. You could contact the vendor and ask it to fix it. You could also write a review for the app store you use and let other people know about the problems. I have done both, because I'm not willing to let such easily avoided mistakes go by unchallenged. If enough people do this sort of thing, I'm convinced that app security will improve.
Dynamic analysis. This one is a bit trickier, though still not tough to do. Use a network proxy tool such as Burp Suite or OWASP's Zap on your main computer (Windows, Mac or Linux). Turn on the proxy on your active Ethernet connection.
Next, configure your mobile device to point its network proxy to the IP number of the computer running the proxy testing tool. Now you'll be intercepting all of your mobile device's network traffic, and you can look inside it.
Some common mistakes to look for here are sending usernames, passwords, session tokens or hardware identifiers through a network without encrypting them. Believe it or not, this is not uncommon. Another mistake that many apps make is to trust self-signed SSL certificates (which both Burp Suite and Zap can automatically generate). By not properly verifying a server's SSL certificate, mobile apps open their users up to man-in-the-middle attacks. This too is sadly not uncommon in today's apps.
If you find any of these things, they should give you pause. Of course, not finding any of these mistakes is no guarantee of safety, but that doesn't mean it's not worth exploring the apps you want to use.
Oh, and if any of the apps you want to use do make any of these common mistakes, think about pointing the developers to OWASP's iGoat (for iOS developers) or OWASP's GoatDroid (for Android developers). Both are free learning tools to help expose developers to common problems and their solutions.
With more than 20 years in the information security field, Kenneth van Wyk has worked at Carnegie Mellon University's CERT/CC, the U.S. Deptartment of Defense, Para-Protect and others. He has published two books on information security and is working on a third. He is the president and principal consultant at KRvW Associates LLC in Alexandria, Va.