0

For my Android application, I wanted to store values such as username, userid and stuff in a sharedpreferences object. However, when I read more about it, rooted users can still have access to those values. So I am wondering, if I store those values in static variables in a class, for example:

class foo{
  public static String username = null;
}

and call it for change in another class for example:

class bar{
   foo.username = "user1";
}

Would users still be able to find out the value of username is user1 in any ways?

4

Any security model that tries to defend against the legitimate user of a device is faulty. Here, your obfuscation tactic will only provide security if both:

  • the app cannot be downloaded, decompiled, and subjected to static analysis, and
  • the app cannot be subject to dynamic analysis, e.g. capturing heap dumps or memory images while the app is running, or by capturing network traffic.

If you publish your app it can be downloaded and analyzed.

Normally the user will be unable to capture heap dumps (e.g. via adb), but this guarantee flies out of the window the moment your app is run in an emulator, or under a non-Google Android variant. Network traffic is particularly easy to capture (unless you use certificate pinning), because users can easily mount a man-in-the-middle attack against their own device.

So you can't generally prevent static or dynamic analysis.


You will have to rework your security model so that you are no longer storing secrets on the user's devices that they are not supposed to have access to. Instead, you may have to introduce a backend server that handles secrets.

Example: API authentication.

Bad design: Your app contains a secret token. Your backend API only accepts requests with that token to prevent unauthorized use.

The flaw: The token can be extracted and used for unauthorized access, and the backend server cannot tell the difference between authorized and unauthorized requests.

Better design: Authenticate the user, not the device. You can then control access per user account, and reject requests with invalid credentials.

Example: third party API authentication.

Bad design: The app communicates with a third party. You have an account with that third party. You have embedded your credentials into the app so that the app makes requests on your behalf.

The flaw: the credentials can be extracted and used for unauthorized access. The third party will think you are responsible for any unauthorized actions.

Better design: let your app communicate with a backend server under your control. This server then communicates with the third party. It can store any necessary secrets securely.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.