Securely store appcheck token with EncryptedSharedPreferences instead of storing it in plain text

[mukswilly]

What feature would you like to see?

I propose the use of the androidx security library, specifically EncryptedSharedPreferences to store the appcheck token.

How would you use it?

Currently, the appcheck token is stored in plain text in the shared preferences. This makes it very easy to extract and abuse on rooted devices where users have access to apps' internal storage. Use of encrypted shared preferences from the androidx library can help to better protect the token i.e not exposing it in plain text.

[google-oss-bot]

I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.

[argzdev]

Thanks for filing a feature request, @mukswilly. Our engineers will take a look into this when they have the time.

[vcoolish]

what's the eta for this one? this is security issue, do you want to migrate to data store with encrypted preference storage?

[sl-ahmedabdellaoui]

Hello, Can we have an update about this security issue ? Or maybe its not necessary to secure the storage of this appcheck token, as i m not sure a rooted device can get an appcheck token 🤔 ? due to the play integrity verdicts for device integrity.

Thank you

[weixifan]

Thank you for this report.

Encryption at rest is a topic we have considered in depth. There are several very real drawbacks, and the attack vectors typically employed against an unencrypted token will continue to work even if the token were to be encrypted. We can explain this statement a bit more.

• Note that the Firebase App Check token is cryptographically signed, and this signature is part of the token. The Firebase App Check token is in fact a JWT. This means security-sensitive claims such as sub and aud that indicate which Firebase app and project the token is attesting cannot be modified without invalidating the token. Firebase backends (and custom backends that use our Admin SDK) receiving these maliciously modified tokens will reject them because their original cryptographic signatures will not match the expected signature of their (modified) contents.
• However, note that replay attacks are still possible, but this is not solved by encryption. This is because an encrypted token is just as easy to pass around as a non-encrypted one. Being unable to see the contents of the token does not prevent an attacker from using the extracted token.
• In order to guard against replay attacks, we recommend using the TTL parameter to perform your desired trade-off between performance, quota usage, and security.
• An attestation provider (such as Play Integrity) guards against rooted devices from ever successfully completing its attestation handshake -- this is the purpose of attestation providers in the first place.
• Finally, note that encryption at rest will necessarily introduce code that impacts both the size and performance of the app. This is undesirable given that encryption of the (already signed) token provides very little benefit to developers.