Assigned
Status Update
No update yet.
Comments
[Deleted User] <[Deleted User]>
Hello,
Thank you for reaching out. I'm going to create an internal feature request. Please keep in mind that this feature request has to be analyzed and considered by the product team and I can't provide you ETA for it to be delivered. However, you can keep track of the status by following this thread.
se...@google.com
se...@google.com
Okay, I'm going to create an internal issue report. I'll let you know when I get any updates from Google Engineers.
se...@google.com
se...@google.com
I received reply from Google Engineers. In general we try to balance between user experience and security. We want to provide more actionable error messages to end users and we also want to expose the ability to look up a user's providers or whether the account exists when an email is provided where a developer needs to know what provider to sign in a user after they enter their email. But at the same time, we throttle these endpoints to prevent abuse and make such attacks less feasible.
[Deleted User] <[Deleted User]>
As far as I can tell there is no throttling happening.
[Deleted User] <[Deleted User]>
That said, even if it's throttled, it still puts us out of compliance and we need to remediate this. The current implementation isn't acceptable for our purposes.
[Deleted User] <[Deleted User]>
Can I get a status update?
Description
Steps to Reproduce:
1. Visit
2. Follow instructions to set up a configure a test site using one of the quickstart applications.
3. Add a user to the API using the /setAccountInfo endpoint (
4. Query the API using the /verifyPassword endpoint (
a. A user that exists
b. A user that doesn't exist
5. Note the different responses from the API:
"INVALID_PASSWORD"
"EMAIL_NOT_FOUND"
Depending on the validity of the user's e-mail address or username, the application will tell you if that e-mail/username is associated with an account.
Attack scenario:
Any unauthenticated user with access to the site can spray the /verifyPassword endpoint of the target application with a list of e-mail addresses in order to enumerate which of those e-mails is associated with a valid account. This can be useful for an attacker looking to target specific users with different types of attacks, not limited to XSS, CSRF, brute force/password spraying and more.
Screenshots:
1.
2.
Mitigation:
Instead of responding with two error messages, respond with "USERNAME_OR_PASSWORD_NOT_VALID" in the API for both situations.