Engine Yard Blog RSS Feed

Note: Engine Yard friend Himanshu Dwivedi, CEO/Founder, Data Theorem has graciously let us post this great piece about mobile security on our blog.

Mobile privacy is one of those hot topics lately. Every week there seems to be another article about a mobile app or platform having a privacy issue. Indeed, Path was recently hit with a $800,000 fine by the FTC for breaches in privacy. The focus on privacy extends across application platforms to even BlackBerry which have been well regarded for their security measures. The tricky part of providing privacy for your customers on your mobile application is that there are many kinds of data stored as well as places this data can be stored. Here are the top 10 tips to ensure privacy for your customers as you develop your mobile application.

Please Don't:

1) Use UDID and equivalents

This feature has been deprecated in iOS 6.0 but still largely pulled. This is an advertiser's dream but it tracks without the users knowledge which raises concerns with privacy advocates.

Recommendation: Generate an app-specific random session ID that can't be cross-linked by other applications.

2) Be careless with geo-location

Treat geo-location tags and data as sensitive. This means that you don't want to send information over the network in clear-text. Another thing to watch for is storing this information client side where there's a cross-link with identifiers, making it vulnerable to hackers.

Recommendation: If you're going to use geo-location, be sure to store it server side but remove it from these systems over time. Long-term storage can imply that you are tracking your customers over a long period of time including where they have been which is a big no-no from a privacy perspective.

3) Do not access contact lists without permission

While Contact lists are a great way to get more users, especially with a "cold start" applications, unfortunately privacy advocates don't like it. The case of Path demonstrates that storing contact list server side and cross-linking is a bad idea and one that may get you slapped with a fine.

Recommendation: Accessing contact list is one thing but strong server-side is a a big no-no. Do not access a user's contact list without permission, even if it means for a better user experience.

Watch Out for…

4) The Copy/Paste function

In iOS you want to be aware of the UI paste board as information stored in the clipboard (aka UI Pasteboard) is accessible to all other applications on the device. This is important because applications have been written specifically to monitor the clipboard.

Recommendation: Even though it's a UX trade-off, disable the UI Pasteboard especially for sensitive fields: username. passwords, phone numbers, addresses.

5) Cache.db

The cache.db file was introduced between iOS 4.x and 5. The information stored on cache. db database file is not encrypted and accessible to anyone who has access to the device. There isn't a great deal of documentation on this so often developers don't realize what information the cache.db is collected.

Recommendation:Turn off caching using NSURLCache settings.

6) Auto-Correct

The iOS caches each non-numeric keyboard tap of the user for the auto-correction feature to work, which cannot be disabled by any application. Since almost every non-numeric is stored, it's important to disable auto-complete for confidential fields such as address, mother's maiden name, city of birth, etc.

Recommendation: Set atuocorrectionType prperty to UITExtAutocorrection NO.

7) Backgrounded Screen

A backgrounded screen is when a screenshot is taken with a state change, such as an incoming call. All applications on the device have access to the screen shot which may include confidential data. Luckily this is an easy fix.

Recommendations: Detect state decision of the application specially applicationDidEnterBackground. When the app is backgrounded, enable a splash screenshot that consists only of nonsensitive data such as the organization's logo.

Remember

8) Keychain

There are keychain dumper tools to dump everything out of the keychain. If you want data that is secure at all costs you shouldn't put it in the keychain.

Recommendation: Many items in the KeyChain are accessible, but just not of the box.

9) Encryption

If the key to decrypt data is stored client side on the device, it only slows attackers with physical but does not protect the data 100%. For offline mode, decryption keys are often stored on the device itself.

Recommendation: To truly encrypt data, ensure the decryption key (private key) is stored server side only

10) SD Cards

External storage (e.g. SD cards) have no file permission protection which means the data is accessible to all applications (copy, tamper, etc). Recommendation: Do not store any private/confidential data on external SD cards. If data needs to be shared between device apps, store the data server-side and allow access to the storage using client-side authentication/authorization tokens. Be aware that the Sandbox model does not apply on the SD card either the Android or Windows phone.

With these tips, your application will definitely be up-to-date with the latest in mobile security and privacy.

With the widespread adoption of mobile applications, ensuring the security and privacy of your application and customer data is paramount. By applying these tips, you will help ensure your application is up-to-date with the latest in mobile security and privacy.


Tagged:

comments powered by Disqus