The apps we write will soon be enhanced by downloadable "packages" using the in-app purchase API. We would like therefore to start securing our content which we wish to allow the users to download/extract onto their memory card (so as to not use up internal memory for our large applications), however, we need to secure the files somehow so that they can't simply be taken from the SD.
Can anyone suggest some possible/simple/common techniques used to do so on Android?
You'll want to look into ProGuard, it's pretty well integrated with ADT. An easy way to get a good ProGuard config file is to create a new Android project in Eclipse, as the newer versions of ADT automatically make one for you. It is used when you right click the project and use Android Tools>Export
I'd think you'd probably want to generate a hash based on some unique device identifier and a strong key of your choosing. A unique identifier for the device can be generated using the technique discussed in this answer. Have the App transmit that hash to your server, and encrypt the package before (or as) it is sent to the user using this hash as a key. Your app will decrypt the data as it is read by generating the key on demand (the same way it was initially generated). Have a look at the MessageDigest class and the javax.crypto package in the API.
Related
I am developing an SDK/API that will be used by apps not written by me.
I want my code to generate a private key once and store it on the device.
This key should be unique per device, I don't mind it being erased on factory reset, and I don't need to extract it from the device.
Sounds an ideal case for the KeyStore (preferably with a StrongBox).
I do want, though, different apps to use the same key to sign (or ask my API to do so)
I could not answer two concerns:
If my API is a library linked (statically) into the app, different apps using my code wouldn't be able to use the key, because the keystore requires
If I package my API as a separate android app, and have the other apps use it using Intents, I'll have to have the user install it manually, because as far as I could tell, Android/Play does not allow for dependencies between apps.
What is the most graceful way to resolve this situation?
I have been doing some security testing on an Android app. One thing I am trying to wrap my head around is API key security; particularly google Places and Maps keys. There are lots of posts that talk about the options, namely compiling keys into source, placing them in resource files, compiling them into a shared library, etc. In my particular case, the Maps key is in the manifest file, and the Places key is in a shared library. I created a signed APK to test how hard it would be to obtain and use one of the keys. I did the following:
Reverse engineered the APK using apktool,
Opened the manifest and grabbed the Maps key,
Created a fake version of the application with the same package structure as the original containing an activity with a google map fragment,
Put the Maps key in the fake manifest,
Ran the application, which displayed the map
Then I:
Created a new class in the fake app with the same package and name as the original with code to load the shared library from /data/data/[package name],
Copied the the shared library from the reverse engineered APK to the /data/data/[package name] folder of the fake app,
Ran the fake app, which then printed out the Locations API key
So in the end, without much effort, I had both keys which I could then use in a fake version of the application.
I'm sure I must be missing something. It looks like the only option for Maps is to store the key in the manifest. What is stopping someone from doing what I did? Surely it can't just be indifference. I realize that someone would probably get caught if they tried to publish their app using a hijacked API key. However, someone could create an app and have people side load it. It would be a huge disruption for customers if the company had to change a hijacked key every time someone messed with it.
I believe you need to go through the Docs for Google API keys again. There seem to have something called restrictions that should be able to help with you ensuring that your Keys are protected and not used on some other application.
I believe that restrictions prevent a request from other domains you have not included from not being able to render.
API Key best practices
There are many way to keep your API key secure. Below links are explained that how to secure your keys.Depending on your use case you can follow one of them
Using Gradle
Using NDK
Using Server Call
In my Android app, I make requests to my backend API and add a auth header value so that only my app can access my API data. I'm using OKHttp which makes it simple .addHeader("name", "value")
However, right now I'm simply hardcoding this header name and value in my Java file. It seems that people are able to decompile Android apps and will be able to see my auth header value.
Is there a way I can prevent this from happening?
This is a very discussed topic and it's always a tradeoff.
Some strategies are
Hardcoded in Java
In shared preferences, assets or resources folders
Using the NDK
Public/private API key exchange
Article's conclusion
What option you choose is probably going to be determined by how much control you have over the backend server. If you don’t have any control then you’re probably going to have to hide the API key using the NDK. If you do then we recommend the Public/Private encryption of the API key using nonces to prevent any replay attacks. In the next article we’ll look at the security implications of supporting earlier Android OS versions, as well as how some Android phones are more secure than others.
Subscribe to our Android Developer Newsletter
Join our Android Developers newsletter to get all the top developer news, tips & links once a week in your inbox
Full article
Possible duplicated question/answer
I have an Android app and I'm saving highscores simply in Shared Preferences. On a rooted device, you can just edit the XML and modify the score. Because in next update I'm planning to add Google Play Leaderboards, I need to store them safely. Now, I'm just saving it and a salted hash of it. But there's one problem: It is possible to decompile it using decompileandroid.com easily and read the way how I'm salting it and reproduce the process afterwards.
I want to be able to sync highscores which were made offline. It's really simple app that is definitely supposed to be played in a bus or train.
Since the customer is in control of the device, and the game is played offline, it will always be tamperable. There is no storage on the device that root cannot access, and there is no way to fully obfuscate client side code so that the user can't reverse engineer it. Your options are to 1) change your design and require closer server-side integration to detect cheating, or 2) to attempt to make it more difficult by obfuscating the APK, and putting in bypassable protections like you have suggested with the integrity checking hash.
You can use internal storage. The details are in the oficial android developer site: http://developer.android.com/training/articles/security-tips.html
I hope it helps.
I am new to Parse SDK. Is it safe to use Application ID and Client Key within the app? as reverse engineering the APK file might reveal the keys. Is there any other workaround to pull them in the Parse.initialize() function.
Like everything else contained in your APK it is only safe if you obfuscate your code. Make sure that you are using ProGaurd when you build your application and have configured it for gradle if you use Android Studio.
If you use ProGuard to obfuscate your code then you wont have to worry about people being able to unpack your APK and retrieve your Parse credentials.
If you want to test that your ProGaurd configuration is correct you can try and unpack your own APK to make sure everything is obfuscated and hidden as expected. This question will show you the process.
This is something that I have always asked myself. In addition to this you could also use a random keygen to connect to random parse database if you were trying to hack data. I tried to find the SO.com post about this but was unable to do so, regardless, I saw someone post that they had their key strings stored in AWS so that they werent in the APK package. In my opinion you shouldn't have to do this but whatever... Parse is pretty sweet when you cut back on development time and their online data portal is nice as well.