How secure is my app?

When it comes to more than a small marketing app, the topic of “security” is often raised and sometimes silently dropped. On the surface it is quite complex and it gains complexity when you dig deeper, talk to experts, discuss the impacts on the app.

Talking about “mobile security” you have to differ between different issues:

1. transport layer security
2. device security
3. data security

The first one is quite simple to answer. There is nothing new here compared to other data connections. You need to secure the data connection to your backend e.g. against man-in-the-middle attacks or connections via insecure WiFis. If you mind your standard enterprise security standards, you really don’t have to mind anything “mobile” specific.

So what about device and data security?

Protect your device

With device security I mean the general security of your device. For every user this should be a minimum of pincode entry to unlock the device. For enterprise usage tools for mobile device management are highly recommended. They come in all flavors from basic complex passwords rules and remote swiping of all data to app black or white listing, enforced updates and usage tracking.

Use simple integrated solutions e.g. from GSuite for the trusted employees in your small business or full blown solutions like MobileIron in your multinational enterprise.

Just keep in mind the typical risk management rules. If the enforced rules are too strict, the users will find a way to sidestep them or stop using the tools that were made to raise their productivity.

That leaves us with the third point of data security or data protection.

Now this is more interesting.

Protect your storage

You did your best to protect your device and how the data is sent to your device respectively your app. Now you need to store the data and make sure, that no other app or other user can simply hack the data and read the personal or crucial information.

The good news is, that mobile OS’ are quite safe by design. The isolation of apps and their data (if no other target like external memory is selected) grants a good level of protection. Using this sandboxing, all data is stored in a container where no other app has access to. Within this sandbox the execution of unsigned code is prevented by mechanisms like integrity checks and ASLR (address space layout randomization).

So if you yourself didn’t open up any gates, your app’s data is pretty safe.

There is still a chance, that an attacker can hack their way into your secured device and into the sandbox and read your memory. If you want to further avoid this, you should additionally encrypt the data.

All data on your device can be encrypted. As a matter of fact, the iDevices are encrypted by default since iOS 8. On Android it differs between manufacturers, device and OS versions. It’s still a fact, that the majority of Android phones is not encrypted.
Since you don’t want to rely on the OS’ and device’s capabilities and the correct settings selected by the ingenuous user, you should bring in a basic level of encryption and security yourself.

The standard way to do this would be to either use convenient SDKs for encrypted databases or to use the encryption API implemented by the OS directly. iOS and Android both provide standard methods like AES-256.

The most often stated problem with encrypted data and databases is speed. Especially on older Android phones, the encryption/decryption during persistency operations can really slow down your app.
If you are forced to be backwards compatible to older devices, you have to weigh convenience against security. How crucial is the data? Would it be a possibility to only encrypt the most sensitive data to speed up some processes?
Maybe you even have to think about the necessity of storing huge amount of data on the mobile device? Huge amounts of data belong to strong and save backend systems.
Keeping the amount of stored data on your mobile device lean also reduces the data to be encrypted.

You may want to keep in mind, that in the submission process of your app you are to answer the question for export compliance for the US. Since every app is distributed via US servers and thus falls under US law, your encryption method is required to be either be pre-approved by the Bureau of Industry and Security or you need to get your approval.

Good luck with that. I tried to understand the process but it seems like a kafkaesque nightmare.

No, seriously: it is a big red tape mess, but basically, if you rely on mass market or open source standards, don’t use a too hard encryption, you shouldn’t run into any problems here.

Last thing you have to decide on, is how to grant the user access to the encrypted data.

Is your app or the secure space within protected by PIN or password? If so, do you cache that entry or do you force the user to re-enter it every time the app comes to foreground?

I was really glad, when my banking app introduced password storage protected by TouchID. Because it is really convenient. You set the password for the app once, then store it and have access to all the information only using your thumb with fingerprint sensors decrypting your original password.
Now be aware, that the thumb acts as a master password to all apps. But the data is stored secure, the access is convenient and to get access, a hacker would need to get hold of your device (not only the backup) and chop of your thumb - or less bloody recreate your fingerprint…

You also may think of two factor access with a biometric feature combined with a simple enough PIN entry. Still convenient but even harder to hack.

Conclusion

So to sum up, nothing is 100% safe. But can be quite safe and in the same breath be convenient which increases the probability of security features being used. Especially on such quick to use devices like smartphones.

You should keep this in mind:

1. Check which data should be stored on the mobile device. Wouldn’t it be ok, to only get the required data on demand? Especially when you can rely on good internet connections.

2. Check which data to encrypt: All or some? Are all data sensitive? Maybe only a part of the apps usage data is really to be secured, so you don’t lose too much momentum during usage.

3. Check which method to use for storing the password. Use standards, the user is familiar with and that are supported by the device. Use biometric functions like TouchID to retrieve a password, which is used to de-/encrypt the data. If the OS or the device offers a convenient access to the data, use it. Keep the hurdles for more security low for the standard user.