4

A friend asked me recently about mobile applications and the security surrounding them. As he wishes to make a mobile app that would handle very secure information such as credit card numbers, I was starting to wonder about the issue of security surrounding these devices. Does it seem reasonable to store sensitive information inside of a mobile app? I wonder this because I have seen dex to class to java decompilers online and I imagine that on any mobile device there is no guarentee that the data in the secure locations is as secure as they would like you to believe.

But, I'm not an expert on these things; I feel like I'm a stranger when it comes to the wonderful world of security. So that's why I ask you this, what is the best way to securely store the data? Is it feasible to securely store credit card information/passwords/etc on a mobile device? If so, what methods should one take in order to assure the users that the best possible measures were taken to securely store their information. If not, what is a good alternative to store all that sensitive information? Even then, with the stories in the news about user data stored in web sites being compromised what measures should be taken to ensure that the data stored there is also secure?

3
  • Handling secure information is different from storing securing information. Do you really need to store this secure info ?
    – Ankur
    Oct 19, 2011 at 6:43
  • 1
    This recent posting may give some useful info about things to avoid. Oct 22, 2011 at 17:31
  • Check into the PCI requirements here, if he is really taking credit card numbers in an app he could be violating those pretty easily. Jul 31, 2013 at 16:16

3 Answers 3

3

You can't realistically hope to protect data from someone who has physical possession of the device. There are APIs that can do that in principle, such as the keychain on iOS and the application private data on Android (or the keychain in recent versions), but these don't resist to jailbreaking. And even on Apple devices, with Apple's efforts to make jailbreaking difficult, a new hole is discovered regularly and most new devices are jailbroken in a matter of weeks.

Apart from people in physical possession (i.e. the user, his entourage and mobile phone thieves), the other party that you need to be careful of is other applications. Users typically install many special-purpose applications of dubious origin (there's basically no vetting on the Android market, not much on the Apple Store, and users can install applications from other places). Here, your best bet is to use the platform's recommended per-application storage, and tell users to keep their devices up-to-date. Unfortunately, that's often not feasible with Android. Using standard APIs has a double economic advantage: it'll be the OS maker who'll bear the brunt of the blame when a security hole is discovered, and you won't waste resources developing your own mechanism (which in all likelihood won't be more secure anyway).

The best way to keep data confidential is not to store it at all, and indeed not to handle it at all. If you can store all data such as credit cards on the server side, it's better; the server side can in principle be secured. Then the weakest link will be the user's password on your server, which he probably stores on the device, because typing a password each time you log on to a web site on a mobile phone is not a realistic user experience.

Note that if you're a merchant handling credit card data, you're supposed to comply with PCI DSS.

Some recommended reading on Security Stack Exchange:

2
  1. Don't hardcode sensitive information in your app's code. If you do, it will be trivial for someone to extract it through reverse engineering. Never hardcode passwords, private keys, etc.

  2. It is reasonable to store sensitive information like credit card numbers or most passwords on application-private storage. For instance, on Android, use application-private storage. Don't store it on the SD card; any other app with the SD card permission (i.e., almost all apps) could read it.

  3. If you are storing a user's password to some existing web service (e.g., their Google password), look for authorization and authentication schemes that don't require you to ask for and store their password. For instance, many Google services support OAuth, and you can use it to avoid asking for and storing the user's Google password (see also here).

  4. If you are talking about storing highly-sensitive information, such as an online banking or Paypal password, I would think twice. Those situations require special care, and you'll probably want to ask a separate question about them if you are in that situation.

  5. If you ever transmit this information over a network, or if you store it to the cloud, make sure to encrypt properly. I suggest using either SSL/TLS (for network communications) or the OpenPGP file format (for data at rest). Keep in mind that many smartphone users are often connected via open Wifi, which is insecure and highly vulnerable to eavesdropping -- so encryption is especially important in the mobile setting.

0

Only download apps from trusted enterprise app stores. However, McRee says that’s not even 100% foolproof. Enterprises should assume that the unknown third-party mobile apps users download should not be trusted. Enterprises should restrict the use of synchronization services, and distribute organization-specific apps from a dedicated mobile application store.

Encrypt data in transit. This is a simple step but one that is often overlooked, Frank Kim, founder of mobile application security consultancy ThinkSec, tells TechTarget. “In the rush to deliver mobile apps, developers are making a lot of the same mistakes they made with early Web apps.

Not the answer you're looking for? Browse other questions tagged or ask your own question.