Avoid storing push notification token insecurely

[SaeedZhiany]

Issue

Recently, our security team has tested my app on a rooted android device. they said they realized that the application's push notification has been stored in a preference file and they wanted me to completely remove or encrypt it before storing.

I don't know what kind of attacks are possible if someone getting access to the token and they didn't explain that for me!

by the way, is it necessary to store the token in preference? if yes, is there any option in react-native-firebase to ask doing some encryption on the token?

the token has been stored in a file named com.google.android.gms.appid.xml in shared_prefs folder of the application.

<?xml version='1.0' encoding='utf-8' standalone='yes' ?>
<map>
    <string name="|T|138535133528|*">{"token":"PUSH_TOKEN","appVersion":"1","timestamp":1572882068592}</string>
    <!-- other key values -->
</map>

Is such a case exists in IOS? I mean does the token stored somewhere in IOS too?

---

Project Files

iOS

Click To Expand

#### `ios/Podfile`: - [ ] I'm not using Pods - [x] I'm using Pods and my Podfile looks like: ```ruby # N/A ``` #### `AppDelegate.m`: ```objc // N/A ```

---

Android

Click To Expand

#### Have you converted to AndroidX? - [ ] my application is an AndroidX application? - [ ] I am using `android/gradle.settings` `jetifier=true` for Android compatibility? - [ ] I am using the NPM package `jetifier` for react-native compatibility? #### `android/build.gradle`: ```groovy // N/A ``` #### `android/app/build.gradle`: ```groovy // N/A ``` #### `android/settings.gradle`: ```groovy // N/A ``` #### `MainApplication.java`: ```java // N/A ``` #### `AndroidManifest.xml`: ```xml ```

---

Environment

Click To Expand

**`react-native info` output:** ``` OUTPUT GOES HERE ``` - **Platform that you're experiencing the issue on**: - [ ] iOS - [ ] Android - [ ] **iOS** but have not tested behavior on Android - [x] **Android** but have not tested behavior on iOS - [ ] Both - **`react-native-firebase` version you're using that has this issue:** - 5.5.4 - **`Firebase` module(s) you're using that has the issue:** - Cloud Messaging (FCM) - **Are you using `TypeScript`?** - yes, 3.5.1

[Ehesp]

Hey. Firstly I don't think we're doing this (cc @Salakar), I imagine it'll be an underlying SDK implementation.

Secondly, the token is worthless without the server token (which should be secure on your server somewhere). It's like a JWT token, the client can see it but without the server token you can't really use it. In this case, you can't use it to send data payloads without the server token.

[tlow92]

You can not send payloads. But you could receive payloads of the user, right? E.g. MFA for banks etc.

[Ehesp]

We don't do anything bespoke here, so whatever the underlying implementation is it's been done by Googles SDKS.

To be honest, it would generally be a bad idea to pass any sort of sensitive information via FCM. The user should be authenticating with something (e.g. your app).

[Ehesp]

Closing for now - happy to keep discussing though.

[SaeedZhiany]

@Ehesp and @tlow92 Thank you two for contributing.

So is there anywhere I ask this question from FCM developers? I couldn't find the Cloud-Messaging repository in https://github.com/firebase repositories list.

[SaeedZhiany]

You can not send payloads. But you could receive payloads of the user, right? E.g. MFA for banks etc.

I'm not sure I could get your point exactly, can you explain more, please?

[Dutt786]

Will You please Explain these Vulnerability in detail

[tkrafael]

@SaeedZhiany if device is rooted, it is possible to use clear text fcm token to listen for notification by just using an http client. Supposing you're creating a bank account and sending MFA token through push service, an attacker could listen for those notification in a laptop and theoretically would be able to access your bank's account/change password/hack.

I don't think that's as easy as it appears. Also, doing encryption just make it harder to attacker. Encryption key must be stored somewhere.