The Lookout Blog

Tips for Developers to Safeguard User Data

Hello.  I’m Tim, and I lead the Security Response Team here at Lookout.

Last week, we talked about a series of Android wallpaper apps that were collecting the phone number, IMSI, and voicemail number from devices and sending them to a remote server over insecure communication channels.  As reported today, Google released these apps back into the Android Market as “there is no obvious malicious code … though the implementation accesses data that it doesn’t need to.”

We’ve been in touch with the developer, and shared with him some recommendations to better protect his users’ privacy.  As we’ve seen, it’s entirely possible to inadvertently put sensitive data at risk without malicious intent.  Rather, developers sometimes do not understand the sensitivity of data that they collect, or the risks inherent in handling that data.

Mobile platforms grant developers access to sensitive data about users, their devices, and their associates. Developers must maintain awareness and act as responsible stewards of the data they’re granted access to.  This is not a new problem — application developers have to contend with handling sensitive data on any platform they develop for.  Smartphone platforms make it easier than ever to access caches of sensitive information, though, and it’s easy to make mistakes.  We’d like to suggest a few “best practices” developers should keep in mind as they create new mobile apps.

• Know exactly what private user and device data you are collecting and understand what that data is.
• Only collect the data you need for your app.
• If you use an advertising SDK, analytics SDK or other 3rd party code in your application, make sure you understand what information it collects and transmits.
• Do not transmit private user or device data over an unencrypted communications channel.  Always use HTTPS/TLS to secure network communications when private data is in motion.
• Consider alternatives to using private user data where possible.  For instance, if you are collecting the device’s primary phone number, IMEI, or IMSI as a unique identifier to save user settings, consider using a one-way hash or a Globally Unique Identifier (GUID) generation scheme that is related to, but does not directly disclose these pieces of data.

Finally, be careful that you don’t disclose data via inappropriate side channels such as shared system logs.  Check logs and audit debug statements to make sure you are not inadvertently disclosing user or device data in released code.

Consider the following code that interacts with Android’s device location provider:

As developers, we often use logging APIs as an easy means to monitor an application’s execution state while debugging.  Access to shared logs on Android is governed by a completely different permission than, for example, access to coarse or fine location data.  Putting that information into shared logs leaks data across boundaries established by the permission model.  Logging data about contacts, browsing history, call history, SMS, and other sensitive user/device data similarly violates the permission model and developers should be extremely careful not to do so.

The world of mobile app development is experiencing explosive growth.  Smartphone platforms are new and exciting and (in some respects) make application development easier than ever before.  As we dive into these new platforms, we need to be aware of the sensitive data we’re accessing and handle it with care.  We all share responsibility for keeping the mobile ecosystem safe and secure.