Photo by Vojtech Bruzek on Unsplash

6 Basic Security Tips for Android Application

Gain your user trust by improving security in your Android Application with these simple tips

Why?

Developing Android Application is hard, but it’s even harder for developing a secure Android Application. So why bother?

If you’re new to developing application, this might not be a thing that interests you. Because perhaps your current goal is only to build as good and as advance application as possible.

But as you keep learning, and involved in a bigger project and developing application that thousands of users use every day… It’s getting more risky to not improving your application’s security.

You don’t want to build a billion dollar app, just to know that there’s someone else just copy-paste your work because they know how you build it.

Furthermore, there’s a lot of people that their hobby is cracking application in Play Store. Either they did it in good faith or not, it’s up to us to prevent them from getting any information to keep application integrity.

With that in mind, let’s see what we can do to improve our application security!

Obfuscation

Maybe you’re familiar with build process that convert your project code into installable APK that run your application. Well this process can be reversed, where by given-APK using the right tool like JADX you can get the project code of that APK… kinda. This process called Reverse Engineering.

Compile VS Decompile

Well they can see the code, so what? What’s the problem? Well your business logic is embedded into the code. So don’t want anyone else can read and trace it.

So how do we solve this? Using Obfuscation, but what is it exactly? It’s a process to make the source code harder for human to read and to understand.

Your Android Project embedded with obfuscation tools using R8 and proguard, just set minifyEnabled to true in your build.gradle like this:

Enabling proguard

With that, every release variant of your application will be obfuscated.

The other thing to consider is to configure the proguard, because there’s some parts you want to keep and some parts you want to obfuscate. By default, if you don’t declare anything proguard will obfuscate everything.

You can declare the configuration inside proguard-rules.pro file.

Here is the list of configuration you can use:

ProGuard Manual: Usage | Guardsquare

And here iskeep configuration that you can try:

Distinguishing between the different ProGuard "-keep" directives

If the APK is decompiled without obfuscation, this is what it will look like:

Decompiled code without obfuscation

On the other hand, if you enabled proguard this is what it will look like:

Decompiled code with obfuscation

Well would you look at that… Imagine it in all of your code, it is near impossible to read how your code works.

In addition to improving your security, enabling proguard actually reduce your application size too.

String Obfuscation

Wait, what’s the different of it between just obfuscation? Well if you could look at the code before, there’s actually limitation of what obfuscation can do. For example, using proguard you can obfuscate:

• Name of class
• Name of method/function
• Name of parameter
• Name of variable
• Name of package

But there’s something proguard can’t obfuscate, that is value of a variable. Although the code is obfuscated, it is still run the same function and algorithm you code it before obfuscation… just with a different name. But by changing the value of a variable it might impact your feature, so it actually a good thing proguard don’t obfuscate it.

But then, inside the value of a variable you might be store something important or confidential like base URL, or endpoint, and even API key from third-party. All of those that you don’t want other people to know and see from your application.

So how do we prevent other people to read our String value? There’s two options that I can give:

• Using NDK, by providing our secret key like base URL, API key, etc inside C /C++ class. The output result of the class is .so and it harder to decompile. Read more about it here:

Hiding sensitive data in android app

• Using StringCare, By Storing your String inside XML resource file and adding an attribute hidden to each value tag. When decompiled, the String will be obfuscated and can’t be read, and only decrypted on runtime. Read more about it here:

GitHub - StringCare/AndroidLibrary: Android library to reveal or obfuscate strings and assets at…

Root and Emulator Detection

Commonly, you want your application run on real device that have not been tampered with anything for example like rooted device or emulator. Because running it in that kind of device might be dangerous. There’s no limit to what it can do to your application, your application data integrity might be compromised.

So it’s a good precaution to detect does your application running on rooted device or an emulator and handle it gracefully if it does.

There’s a lot of method to determine those things, but rather than doing it on your own… You can just use what everyone else already do that for you, like:

• Rootbeer , Simple to use root detection
• EmulatorDetector , Emulator detection tools
• SafetyNet API , Anti-Abuse API that assess Android Device that run your application

Of course there’s no 100% method to check does the device is rooted or not, but it’s a good precaution nonetheless.

SharedPreference Encryption

We love using SharedPreference to store our values locally in the device, such as access token, or credential, etc. But if your application can read it, does anyone else can? Well by default yes.

SharedPreference inside your directory

Storing a new value in SharedPreference resulting you creating a new tag in xml file inside your application directory. This xml file can be opened and the value inside can be used for bad things. If you store your api key there, well too bad for you.

What you want to do is encrypt the name and the value of those SharedPreference so it can’t be used outside of the scope of your application.

Here is some library that can do that for you:

• Armadillo , shared preference implementation for confidential data in Android
• EncryptedSharedPreferences , Wraps the SharedPreferences class and automatically encrypts keys and values using a two-scheme method

So for example before using encryption, your SharedPreference will look something like this:

SharedPreference before encryption

And after using the encryption, it would look something like this:

SharedPreference after encryption

Local Database Encryption

Either using old plain SQLite, or Room, or even Realm… Using local database is such a common feature that developers use in their application. For example if your application supports offline capabilities, you probably store some data inside local database like transaction, favorite menu, etc.

But is it safe? Does anyone else can read what I store inside local database?

Local Database inside your application directory

Well just like SharedPreference, you can actually access your local databases inside your application directory. And even you can pullout the database to your machine and open it with DB Explorer.

So to prevent other people to read the content of our database, Don’t forget to encrypt your database!

If you’re using Room Database or plain SQLite, you can use sqlcipher to do that for you. This is sample code to do that using sqlcipcher:

Certificate Pinning

Forcing all of your web service to support HTTPs is a great way to secure your connection, but there’s always more that you can do. Even by using HTTPs, there’s always a threat of something like Man-In-The-Middle attack.

Man-In-The-Middle attack basically means when a hacker pretends to be the service you’re connecting and allowing them to intercept communication between your application and your service.

One of the way to solving this is Certificate Pinning or SSL Pinning. Where we validate the server certification on the client-side (application). And doing that in Android is pretty easy, here is three ways of SSL Pinning in Android:

• TrustManager , This is old-school way by using mechanism from package javax.net.ssl
• Network Security Config , This solution is provided for Android API Level 24 and higher
• Using Okhttp, if you’re using Okhttp for as your Android HTTP Client, there’s actually a function to pin your certificate to Okhttp class, like this:

Certificate Pinning using Okhttp

Obviously, there’s still so much things you still can do to improve security in your Android application. But with this 6 tips, you’re up for a great start! Keep learning!

Learn more about what you can do here:

Introduction to the Mobile Security Testing Guide