[firebase_auth] Security concern about persisting authentication state in android app

[marinalexandru]

Observations and references

Our findings indicate that the tokens (both the Firebase user token and the refresh token) are stored in shared preferences at app level (com.google.firebase.auth). In this Android security recommendation https://developer.android.com/topic/security/best-practices#internal-storage the note states that an encrypted file should be preferred for sensitive data.

Expected behaviour

Those token values seem to be stored in plain and considering the above, we were expecting to find at least the shared prefs values encrypted.

Further action

Is there a way for us to change modify this default behaviour?

We were thinking either to allow the caller to specify the shared preferences dependency and in this situation we could provide an encrypted instance of shared prefs. https://developer.android.com/reference/kotlin/androidx/security/crypto/EncryptedSharedPreferences.html .. or expose a mechanism to allow the caller to encrypt/decrypt the values himself.

Original post

Was originally addressed on the Flutter thread https://github.com/FirebaseExtended/flutterfire/issues/4220 but this is related to the native SDK more than with flutter fire.

[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.

[malcolmdeck]

We've filed b/179046076 and are considering this internally. We'll let you know when we have further information

[marinalexandru]

@malcolmdeck Thanks! And please let us know if anything is found.

[Gregory991]

Any update on this? Our pen testing team also caught this and it would be great to know if it's going to be fixed or not and how much of a vulnerability it is.

[prameshj]

Thanks for checking in on this. We went through pen-testing as well and this was brought up as a low-risk item, because the threat model is where 1) an attacker either has access to a rooted device to steal the tokens 2) a victim on a rooted device granted another app permissions to read shared preferences.

We will continue to track this via the internal bug.

[vitor-soares-iteam]

Any updates? Our pen testing team also caught this issue.

[argzdev]

Hi all, checking on our internal bug link, there hasn't been much of an update for this. However, this is within our roadmap. We will keep you posted once we have further details.

[marinalexandru]

It is good to know it is on the roadmap. Thanks for the update!

[nissaba]

Having same problem. any update. its been more then a year since last update here. ???

[Hari-Nikesh-R]

Hey @marinalexandru Any update on this, It would be great if there is any mechanism that would help to encrypt the token information that is stored in the android devices.

[vijayjpatient]

@malcolmdeck @argzdev

We are facing this issue again with our pen test. We would like to at least know if this will be resolved any time in the future. If not, could you please provide a statement regarding the security concern?

We're being put in a situation where either we have to have a fix or valid statement regarding this to pass it to security team or we have drop Firebase usage entirely and move to something else.

At this point, this is treated as high critical issue. Timely response would help us plan our priorities.

Thanks in advance.

[msaudiblink]

Still no updates? We are facing the same issue with our pen test.

[ayanvishwaka]

Hi @msaudiblink,

The latest release of Firebase Auth Android SDK for version 23.2.1 should resolve this issue, as this version encrypts persistent data for firebase auth (including access/refresh tokens) inside shared-preferences.

[pamartineza]

Heads up for everybody in this thread, encrypting preferences in version 23.2.1 has broken app backup and migration to new devices -> https://github.com/firebase/firebase-android-sdk/issues/7111