Best place for storing user login credentials in Android

Question

I am creating an android app, and i cannot(?) find any information on authenticating a user of the app on Google App Engine (without using the user's Google Account).Is it good practice to store username and password on the android device and then store the data used by the app on Google App Engine?

Answer 1

You should NOT use SharedPreferences, despite how secure Google will tell you they are, for the simple fact that rooting habits are widespread by both power and wannabe-power users.

In rooted systems, authorized apps will be able to access the internal storage /system partition, thus access the root-owned encrypted XML files where Android stores SharedPreferences, WHICH BECOME CLEARTEXT FOR ROOT-AUTHORIZED APPS. So if a compromised phone happens to have an app that stores such data and the user has a habit of abusing same email/password for different services, the attack vector is pretty straightforward to compromise credentials for multiple services, despite whatever warnings the user dismissed when rooting his phone or giving the app such permissions, because, well, those warnings just aren't clear enough.

Alternatives are manual encryption of persistent storage for credentials, using custom, variable seed, salted algorithms. secure-preferences lib is a great alternative which pretty much does everything for you in a transparent way, with the added benefit of implementing Android's SharedPreferences interface, keeping most functionality of default sprefs with minor tweaking (look at their samples).

2016 Edit: I just felt I needed to come back to this question in 2016 and add a nice reference to the Apple vs FBI drama to alter the OS in the San Bernardino assailant's phone. So, imagine you have a phone that is easily rootable, like most Android's, and that might even be rooted by default or doesn't need to wipe data to root. The FBI doesn't have to demand anything from Google or your company if they wan't to get your credentials. By using stuff like secure-preferences, you place the same type of responsibility Apple decided to undertake by only making your own system (in this case, your app) able to access those credentials. You do get to be annoyed by the FBI if they so desire, but giving your users the sense that you, not the underlying OS, is the only authority having direct control over those credentials, is something I'd rather have in my product.