-6

I have an app and it stores data in shared preferences which can be easily changed using something like root explorer. So, how can I keep settings and be sure that user won't be able to edit them even with root access?

closed as off-topic by MetaFight, user22815, Ixrec, Robert Harvey, user40980 Dec 13 '15 at 1:37

  • This question does not appear to be about software engineering within the scope defined in the help center.
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 3
    I'm voting to close this question as off-topic because it is asking about implementation, but requires additional details and clarification to meet migration quality standards. – user22815 Dec 12 '15 at 20:28
1

Not at all. Anything that is stored, transmitted, or processed by a device under another entities control, can be read and modified by that party. This most disturbingly applies to anything done in “the cloud”, but also means any user of your app can technically (though not necessarily legally) disassemble your app, modify any stored data, …. The only way to stop this is to store any data on your servers, but this might have negative privacy implications for your users, as it exposes the user to the same trust problems in you that you have in your users.

One possible half-solution would be to digitally sign the configuration values using public-private cryptography. This allows you to check that data has not been tampered with:

  • your app changes configuration values. It calculates a secure hash of the config values.
  • the hash is submitted to your server through a secure channel. The server signs it with their private key and returns a signature.
  • the new config is stored with the signature on the user device.
  • when the config is loaded, the hash is calculated. It must match the stored signature when using the known public key of your service.

Failure scenario: an attacker changes the config and signs it with their own key. They also modify the app to use a public key provided by them, rather than the key of your server. Techniques such as certificate pinning won't work because the attacker can modify your app.

So, why shouldn't users modify the configuration? Clearly, that voids any warranty for proper functionality of the app, so most people don't do that. If the security of your service relies on the app not being tampered with, that is bad – for you and for all your users. Anything that must not fall into wrong hands must not leave your hands, so don't give everyone access by putting the secrets on an app store. This is one reason why online services have largely moved away from shared secrets (such as passwords), and instead favour transient secrets (session tokens, one-time use tokens for 2FA or CSRF-prevention) and protocols such as OAuth to allow a limited-trust 3rd party to access a resource on behalf of a resource owner, without the resource owner having to disclose their secrets.

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