Firebase fetchSignInMethodsForEmail is soon unsupported. Do we need it?

[CritiqalPete]

Google Firebase support calls out this method as vulnerable to an email "enumeration attack"

Is this being used for the Authenticate by Apple or Google feature? If so, we need to replace/update.

A search shows this method in two pods: RNFBAuthModule FirAuth

and two node modules: auth-public auth-credential

if it is unused, we can ignore.

---

We highly recommend enabling email enumeration protection on all your projects after testing with your app.

If you currently utilize fetchSignInMethodsForEmail (doc examples: Java, JS, Swift), your projects will be affected. When email enumeration is enabled, the fetchSignInForEmail API will fail. Linking anonymous authenticated users with an email address will also not work prior to SDK version 22.3.0 for Android, 10.18.0 for iOS, and 10.6.0 for Web.

A full list of affected flows is also available for review.

Additionally, FirebaseUI libraries first run fetchSignInMethodsForEmail before allowing a user to sign in with their preferred method. If you have a dependency on the library, you should evaluate impact before enabling email enumeration detection. Once FirebaseUI libraries are updated (issue 1, issue 2, issue 3, issue 4), you should enable email enumeration protection.

One or more of your projects have Firebase Auth or Google Cloud Identity Platform enabled.

We’re here to help If you have any additional questions, please look through our documentation center.

[CritiqalPete]

note that we have a dependent task to enable enumeration protection once this has been addressed.

[CritiqalPete]

need to determine the actual risk level as well as the effort to update our methods.

[nglover53]

Some resources on Firebase enumeration attacks:

StackOverflow: Shows a recent (~3 month) post from user inquiring about deprecated Firebase fetchSignInMethodsForEmail. The following essentially describes:

1. The nature of the attack: Which is a brute force method of hacking user accounts by continuously passing an email to the API and verifying correctness by checking the API response.
2. A trivial way of addressing the vulnerability: "For now, you can disable Firebase's email enumeration protection to ensure the fetchSignInMethodsForEmail method works. If that method disappears in the future though, there is no alternative API" (see source below)
3. A non-trivial solution which is also susceptible to enumeration attacks: Could store the same information in a database and and create a new API.

enable/disable the protection against email enumeration attacks

Analysis: I am unsure of how practical the non-trivial solution is for a user base as large as SCORES.

Google Cloud Services, Enable or disable email enumeration protection:

Additional information of note:

1. Projects created before September 23rd 2023 do not automatically have email enumeration protection enables
2. When email enumeration protection is enabled, your project has the following behavior:

• When you make a password reset request, a verification email is sent only if the email address exists; when you make an email address change request
• A verification email is sent only if the email address doesn't already exist. In both cases, there are no specific error messages indicating when emails aren't sent.
• In addition to using email enumeration protection, consider taking measures to prevent abuse of your project's sign-up endpoints that continue to return EMAIL_EXISTS errors. The following are some ways to do so

3. Users cannot change their email address without first verifying the new address. For example, you can no longer change a user's email address with the update REST API, the setAccountInfo REST API, or the [updateEmail]
4. It is possible to disable EEP if certain failsafes exist, although this is not recommended:

Conclusive Recommendations from Google Cloud:

1. If your apps don't rely on any of the behaviors described earlier in this guide, we recommend that you enable email enumeration protection immediately.

If your apps rely on any of the behaviors described earlier, we recommend that you begin migrating away from doing so, and enable email enumeration protection as soon as you can.

https://cloud.google.com/identity-platform/docs/admin/email-enumeration-protection

[nglover53]

Notes from Triage (4/5)

@CritiqalPete

• As far as a massive attack on SCORES, the possibility seems pretty low
• Will be encounter a technical debt problem later if we leave this alone for now?
• Team is leaning toward putting this issue down for now because of low risk and it seems that SCORES likely does not currently have EEP enabled because it is a project predating the auto- opt-in release September 2023

[za-zohaib]

@CritiqalPete tried to find "fetchSignInMethodsForEmail" but it seems like recent updates have fixed this so its not looking as an issue for us. Thanks