Data Security in App Development – Part 2 – Developing for Android

Just like in iOS the issue of data caching by the keyboard is present in Android. Sensitive data, such as passwords, can be cached by the application via the text fields. Text fields in Android may have different input types, and they are configurable by the developers. Most text field types such as “text”, “email” “webAddress” indicate how the keyboard should behave with regards to the data typed in the given  field. In this case, it is responsible for turning the user’s caching mechanism and user dictionaries on/off. To disable this function for a given field it is necessary to set the appropriate input type that will block these functions; such as one of the “password” types. Not only will this block auto-caching, but it will also prevent from copying the input to the clipboard.

Generally, the HTTP protocol is used to transfer the data between an Android app and server. But, the data shared by this protocol is not encrypted; risking a leak of sensitive user data. You will need to replace the HTTP with its encrypted version i.e., HTTPs. HTTPs is based on TLS/SSL certificates and enables developers to add a significant amount of security to the data being shared or transferred.

Logs are another vital element to consider while developing an Android mobile app. The application logs are useful for developers but, unfortunately, the logs do contain sensitive information like passwords or access tokens and are retained locally on devices. They are publicly readable and accessible by several other apps installed on the same machine. The best way to deal with this is to ensure that your production build of the app does not contain them at all.

Mobile security in Android can also be enhanced by securing database files. If you are using SQLite then it is advisable to use SQLCipher extension which is completely open-source.

Android, like iOS, uses the same TLS authentication process and has the same problems regarding certificates. As with iOS it’s recommended that you use certificate pinning to prevent a man in the middle attack.

Generally it is best to store the pins out-of-band embedded as part of the app. If you are concerned with data leakage when your app is decompiled or reverse-engineered then obfuscating the keys is not hard to do on Android. ProGuard and DexGuard can help in this regard by obfuscating the pins. Obfuscation may be especially important if you store a backup key that is not currently in use to help hide it from prying eyes.

If your minimum SDK is Android N (API 24) then the implementation couldn’t be simpler as Android has a new API to handle this – Network Security Config. Even better this configuration even works for WebViews with no additional effort on your part.

Note that, when using certificate pinning, you should always include a backup key so that if you are forced to switch to new keys or change CAs (when pinning to a CA certificate or an intermediate of that CA), your app’s connectivity is unaffected. Otherwise, you must push out an update to the app to restore connectivity.

On Android, with the simplicity of decompiling an .apk it’s highly recommended to use Proguard as an obfuscation tool. This helps safeguard applications using a licensed server and increases the difficulty of ‘reversing’ your code.

You can also write the important parts of your code in C/C++ and add them as a compiled library. While it can be disassembled into assembly code; reverse engineering a large library from assembly is extremely time-consuming. Java is much easier to decompile in comparison to C/C++.

Another solution is to keep the code that you don’t want to get out on a server that you control. When you stop distributing the key parts with your .apk  it makes the attacker’s work much more painful.

Whichever operating system you have developed your app for it’s definitely worth including a security audit in with your definition of done. We recommend running through the OWASP Mobile Application Security Verification Standard guides and ensuring that your app at least meets their level 1 standards. For apps that are dealing with sensitive or large amounts of customer data then it’s worth ensuring the app is upto the Level 2 standard. The MASVS is a security checklist for mobile applications published by a leading not-for-profit organisation focused on improving software security.

This is something where it can be worthwhile to take this to a third party to get an independent review against the OWASP standards.

It’s also worth keeping up to date with ongoing changes to the Apple and Google Guidelines regarding security. These change frequently but both businesses have become more security focussed over the last couple of years and frequently release new security tools with their larger OS updates.

You’ll never fully mitigate the risk of losing user data to a concerted effort by well-funded and tenacious attackers. However, it’s important not to allow your app to be the easy point of entry for malicious actors. The harder you can make things for them to potentially access sensitive information then the more likely they are to give up before reaching it.