With all of these news going on, it is increasingly more important to plan for and make secure mobile apps. Here at Wanari, we always research new ways of protecting the data of your app’s users. I recently wrote a technical article about Tresorit’s new end-to-end encryption tool, called ZeroKit and received some questions about the bigger picture and of general app security. This post is dedicated to clearing some general points about mobile app security and development.
Application security is a crucial issue during development, while you must consider the effort, and whether it matches the real need.
In a lot of cases there is no need for extra security, for example if you do not store or transfer any private data.
Kinds of mobile app security issues
It is essential to know the depth of the security you need at the begining of the planning phase. It can be difficult to implement, or even can cause architectural problems later on if you figure as you go.
Security issues can be separated into three plus one main groups. These are the following: application code/codebase, data, networking, and security of security.
Code security (our risk):
When we start to distribute our app, it becomes reachable by almost anyone (mainly uncontrollably). There can be people who want a peek into your app, out of curiosity or explicitly for causing mischiefs. This is called Reverse Engineering. There are several tools for all the platforms, even integrated into the IDE (Integrated Development Environment), that help reverse engineer the applications.
iOS by default seems to be more secure in this aspect than Android, but we can make countermeasures to make it more difficult for the priers.
Android Studio itself has a tool where you just drop the APK file, and it unpacks it for you, revealing the whole app. With this solution anyone can copy your code, your product, and then repack and resell it or include malicious things inside.
Data security (customers risk):
Storing and transferring data can cause real privacy problems. Good to know in file storing: there are several places apps can save their files. They can store them in the app, where they “cannot” be reached, and anywhere on the device, where they are absolutely public.
It is essential to use https for online communications nowadays. iOS currently has a backdoor to enable simple http connections, but they are by default prevented and they say it will be removed in the future. Android has no prevention for nonsecure connections. Without https, anyone can watch the communications on the network in clear text, for example using WireShark. But even with https there can be men-in-the-middle attacks (someone pretending to be the server you are trying to connect to) while they tap into your data.
Security of security:
If your dev team secured their code, storing, and communications too, you may think it’s closed, no one can hack your app. It depends on how well the secrets have been stored. Of course every device can be rooted or jailbreaked, and then they can be insulated deeply. Previously I thought iOS is a quite secure platform, then I Googled around a little bit and came across several videos demonstrating, how to modify the OS at runtime.
Previously there were several widely used apps, that used unsecure connections, and or stored files, without any encryption what is really sad.
Prevention of these app security problems
- Code security:
Developers can make their code far more unreadable even if someone could reverse engineer it. This technique is called code obfuscation.
- Android has a built-in solution for this, called Proguard. Proguard is a quite handy tool. It has its own language to write the configuration file, but it can make my own code unreadable to me too. There is another undisputable adventage of Proguard, it can – as it’s function is called – minify the codebase (remove unused, or unnecessary code snippets). Android has a limit in method-count (65k), above that, the app has to be multidexed (it can have several side effects, therefore it should be avoided), and it can be reached easily with adding several libraries, but minifying can reduce these numbers. There is a fine-tuned (offering more functiality) commercial brother, called DexGuard. DexGuard has the same feature-set than Proguard but more, with Runtime Application Self-Protection (RASP), and it can be extended with addons too.
- iOS has third party libraries to achive something similar to Android. There is also an iOS brother of DexGuard shipped by the same company, which is called iXGuard. It combines several features like obfuscation and encryption, to make reverse engineering way harder.
- Data security:
First of all, you should decide if there are any data to store, isn’t it enough to store just in memory, cause if you store nothing, then there is nothing to be stolen from you.
If we are talking about files, or databases (one way or another they are files also) and security, then we converge to encryption. It is worth keeping in mind that several third party database solutions have encryption options built in (Realm, Couchbase etc.). Encryption brings its own problems, e.g. where to store the keys to keep them secure. It will be covered in the third section:
- Network security:
All your connections should work over https, that’s a must. The default built-in security guarantees the certificate chain is valid, but if you also want to prevent men-in-the-middle attacks, you should also use Certificate pinning. Certificate pinning is a technique where the hosts are matched with their certificates directly. Fortunately all the popular libraries in mobile developer circles contains solutions to make certificate pinning implementation easy. Certificate pinning is a good thing, but it has a little drawback: if the server rotates its certificate on a regular basis, then your application will need to be updated regularly (Google works this way).
- Security of security
It is very important that storing credentials, or anything used to secure our data, cannot be stored in public, or at easily reachable places (for example SharedPreferences or NSUserDefaults). You can use the best solutions for encryption, if you fail to hide your secrets well.
There are far better options on both platforms for our rescue, KeyStore on Android, and KeyChain on iOS. On Android when the same credentials are used for several apps AccountManager should be used, it’s cloudbased so no password stored on the device. These are best platform given solutions.
Fortunately there are other options too. Some say the best solution is to store no credentials on the device at all. You should get them from a trusted cloud, like AccountManager. Tresorit, well known about it security, started to roll out its solution into public use, call ZeroKit. They call it zero knowledge technique because no one knows the secrets directly. I also have a detailed technical post and demo app about ZeroKit.
There are other global options for handling signin procedures, leaving it to trusted services like OpenId Connect for authentication and OAuth2 for authorization. This way you can use your Google or Facebook account instead of bothering with your own authentication, and it also indentifies your application, not just the user. There are other adventages with these accounts; your app can gather or post information to or from these sites in an authorized way through permissions.
Almost every year, a list of top security risks is gathered, it’s called OWASP.
In the first place it covered server issues, but later it had grown a mobile branch. It covers the 10 most recent vulnerablilities. It gives a fine detailed description, and some tips to help preventing them (developers should check it out regularly) for each issue.
Your mobile app is worth a test
When your app is considered to be done, there are a bunch of companies who offer security testing for applications (WhiteHat or Cigital to mention a few). If you use them, you can ensure that your app performs by security requirements.
All in all
You should keep in mind that as soon as your application is on the market, it is immediately exposed to several threats. This is what makes securing well crucial. I hope I could give you a bird’s eye view on app security and why it matters. If you have something to add, leave a comment!
iOS security: https://code.tutsplus.com/articles/how-to-secure-an-ios-app–cms-26533
iOS securtiy test results: http://www.pcworld.com/article/3147513/security/app-developers-not-ready-for-ios-transport-security-requirements.html
Certificate pinning: https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning
Authentication and Authorization: OpenID vs OAuth2 vs SAML: https://spin.atomicobject.com/2016/05/30/openid-oauth-saml/
OpenID Connect and OAuth2: https://github.com/mspnp/multitenant-saas-guidance/blob/master/docs/appendixes/about-oauth2-oidc.md