Best way to secure Android app sensitive Data?

Question

Yes this is a pretty general question but I\'m trying to get a feel for the best way to handle an app that touches base w/ a webserver that distributes sensitive data to the

Answer 1

Storing sensitive data on the device

That depends very much on your audience. Normally, the Android OS prohibits apps from accessing each other's files (i.e. databases, preference files, regular files stored in the app's private directory) through proven Linux file permissions. However, on rooted devices an application can obtain root access and read everything. A few things to think about:

1. If you know your users won't have root (e.g. if you are not distributing the app through Android Market, but only in your company, or something like that), you can simply rely on Android's filesystem-based security.
2. If a user does get root access, he will be very careful what application he gives that priviledge to
3. If an app does get root access, it can wreak a lot of havoc. The information in your app could be the least of the user's worries.
4. Rooting leads to zero warranty. Including in apps. You can't be held responsible for leaking information on a rooted phone.

To conclude, if your information is not super-duper sensitive (e.g. credit card information), I'd suggest just sticking with the default security provided by Android (i.e. save everything in plain text, knowing other apps can't access it).

Otherwise, encryption is the way to go. It's not 100% secure (a hacker could de-compile your app and figure out how to decrypt the data), but it's a major pain to crack and will stop most hackers. Especially if you obfuscate your code with something like ProGuard.

---

Transferring sensitive data from the server to the device

You have a few options here. First of all, always use HTTPS. After enabling HTTPS, here are two extra security measures I would propose:

1. Use an API key system. Include this API key in all your requests and check it on the server side before sending any response back. Remember that since you're using HTTPS, an attacker would not be able to just use a network sniffer to find out your API key. However, this is pretty easy to figure out if someone decompiles your app, which is why you can obfuscate it even further (besides using ProGuard). For example, you can keep the API key broken up into pieces all around your code (for example as static members in two or three classes). Then, when you send a request, you just concatenate all those pieces. You can even apply some other sort of transformation (e.g. bit shifting) to make it even harder to figure out from the decompiled code.
2. You can generate a key every time you send a request. That key would be generated by using a bit of logic that only you know, so that you can implement it client- and server-side as well. For example, a request could include the following parameters:
   time=1321802432&key=[generated-key]
   where generated-key is generated from the time parameter. For example: md5(time + salt). When the server receives this request, it can do two things:
   1. Check that key is indeed equal to md5(time + salt) (note that only the client and the server know the salt and it can be obfuscated similarly to the API key above), and
   2. Check that time is not too far back in the past (e.g. if it's more than 1-2 minutes in the past, consider the request invalid).

The second method is more useful if you are also doing plain HTTP requests, where everyone can see the parameters being sent. Also, it's much harder to figure out from decompiled code. Especially if you spread the key calculation logic across multiple classes.

However, note that nothing makes it impossible to crack your app. You can obfuscate as much as you want, if a hacker is really determined to get to your data, he will be able to so by decompiling your application and spending many sleepless nights passing through your code and figuring out how the requests are formed. The only real way of securing your data is by asking your user for a password, besides doing all the work I wrote about above. You can't get a password that only exists in someone's (the user) head from decompiled code :).