3

I have a web application which stores its accesstoken in localstorage. It also has an android application which is basically a webview wrapper of the web application.

In this case, the local storage will be saved to apps data folder, say /data/data/com.myapp.test/app_webview/, as a .localstorage file. As long as the phone is not rooted, these files won't be accessible to anyone else other than the same app and root. All good :)

But if the devices is rooted, the file becomes accessible for anyone. Since the localstorage contains the accestoken for the current session,here, I assume the app may get compromised. Below are my queries.

  1. Is there a more secure mechanism to store the accestoken that localstorage?
  2. Can this be achieved with sharedPreferences/keystore? If yes, what will be the things affecting app performance?
5

Can this be achieved with Keystore?

I don't think that fits your use case. Keystore is designed to store cryptographic keys that will be used for encryption, decryption and signing. The idea is that these keys will be out of reach of the application using them, so basically, if you need something signed or encrypted, you call a system function that has access to the keya, but you can't get the keys themselves. This protects them from compromised applications. This doesn't work for you, since you need access to the access token itself.

If you used Keystore to encrypt and decrypt the access token, this would protect the access token from other processes (or from being extracted by forensic software from the filesystem - but see about access token expiry further down...). So that would definitely enhance security. But if your app was compromised, an attacker would still get access to the decrypted access token.

Is there a more secure way than using localstorage?

I'd say that if you want to protect against someone with root access and/or a compromised application, then no. You can't protect a secret from root, no matter where you store it on the device, except maybe in trusted computing platform hardware (this isn't exactly true - linux systems support security capabilities which root has by default, but may be denied by the kernel if so configured - but I think that's not very relevant for this discussion)

The problem with protecting from root is that root has access to everything your app can access, so even if you encrypt your access token, root would have access to the encryption key and could decrypt it. The same holds when your application is compromised.

One way to add a bit of security might be to have a service which is housed outside the device do an additonal layer of encryption and decryption of the access token based on a revokable key, so if the device was lost, you could revoke the associated key and then the encrypted access token on the device would be useless. But for this solution, you'd need to have two layers of encryption, one on the device (otherwise, you'd open up a new vulnerability by sending plaintext access tokens over the network to another service) and one on the service.

However, this strikes me as a ludicrous amount of work to protect an access token (it might make a bit more sense for a long-lived renewal token). Access tokens are generally short-lived and if you deleted an access token as soon as you no longer needed it, that would also increase security.

Storing the access token somewhere other than localstorage might, however, be more secure than localstorage because localstorage is accessible using javascript, so if your webview was infected with malicious javascript, it could steal the access token. But since your own code in the webview probably needs access to it, you're out of luck.

BTW: I'm assuming you're talking about a oauth access token. oath was originally designed to solve authorization for server-side applications which are used by user agents (browsers). oauth 2 then extended this to include authorization and authentication flows for other scenarios, such as for javascript apps running in the browser or apps sitting on devices controlled by the users themselves, but there are a few people (the original editor of the oauth 2 spec among them) who complain that oauth 2 support for these alternative scenarios isn't very good/secure.

  • With non-rooted device, backup that package still works and gives a chance for attackers to steal the data. – Ender May 14 at 9:26

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.