Time based user enumeration [identitytoolkit.googleapis.com]

User enumeration vulnerabilities can expose sensitive information about whether an account exists in a system, often through subtle indicators like timing discrepancies in server responses. This article discusses a discovered case where response timing discrepancies in the password reset functionality reveal whether an email is registered. However, the provider, Google, clarified that this behavior in identitytoolkit.googleapis.com is intentional.

The vulnerability is associated with the server’s response time when handling password reset requests on Google Cloud’s identitytoolkit.googleapis.com domain.

The application reveals whether an email address is registered through a measurable difference in response times.

The domain identitytoolkit.googleapis.com is part of Google Cloud's Firebase Authentication service. It provides APIs and tools to handle authentication workflows in web and mobile applications.

Firebase Authentication is a service offered by Google to simplify user authentication for developers. It supports several authentication methods, including:

Email/password authenticationPhone number authenticationFederated identity providers (e.g., Google, Facebook, Twitter, and Apple)Anonymous authentication

To replicate the issue, use the following script:

wget https://gist.githubusercontent.com/pdelteil/70d8cdbd7a7e76907fca7f2b80029d5a/raw/1d5bef74b38e716661657d521e27b88ae0707024/timing.sh -O timing.sh
chmod +x timing.sh

# Check a non-existing account with 10 requests
./timing.sh 10 null@null123.com

# Check an existing account with 10 requests
./timing.sh 10 prueba2@info-sec.cl

When the account exists: Response times range from 400 ms to 700 ms (average ~587 ms).When the account does not exist: Response times range from 50 ms to 200 ms (average ~75.83 ms).

This timing difference allows attackers to infer the presence of registered email addresses.

Sample Timing Data

This data shows a clear difference in response times between registered and unregistered email addresses.

The vulnerability stems from the application’s password reset POST request:

POST /v1/accounts:sendOobCode?key=[API_KEY] HTTP/2
Host: identitytoolkit.googleapis.com
Content-Type: application/json
...

{"requestType":"PASSWORD_RESET","email":"flyter1@gmail.com","clientType":"CLIENT_TYPE_WEB","continueUrl":"https://redirect.url"}

When a registered email address is provided, the server performs additional operations, causing longer response times. For unregistered emails, the process terminates quickly.

After reporting this issue to Google, their security team reviewed the behavior and responded that it is intentional. According to them, this design decision may align with usability or operational priorities. While intentional, it raises potential security implications that developers and organizations relying on this service should be aware of.

User Enumeration Risks: Attackers can still harvest valid email addresses.Potential Follow-Up Attacks: Harvested emails may be exploited in phishing campaigns, credential stuffing, or other attacks.

Even though this behavior is intentional, application owners can take measures to reduce potential risks:

Application-Level Obfuscation: Add uniform delays or proxy server responses to mask timing discrepancies.Generic Messaging: Present the same user-facing message for both scenarios, e.g., “If this email exists, we will send a reset link.”Rate Limiting and Monitoring: Implement rate limiting and CAPTCHA to mitigate automated enumeration attempts.