I see companies trying to solve a similar issue on their password reset forms. They ask you to enter an email address - then give you a reply "if that email exists, we have sent a password reminder there".
The problem is these sames sites have a self-signup, using a unique email as your login. So you can already find out if an email address is in use or not.
If you've going to 'leak' the data one way or another, dont sacrifice UX for the sake of it.
This isn't an issue, you can do the same thing with the main login form and a number of undocumented APIs. I've never seen anyone else acknowledge "confirmation of email address existence" as a security issue and I don't see why Google should be the first.
There's a more API friendly endpoint to do this that returns a nice JSON response, like this:
{"input01":{"Valid":"false","ErrorMessage":"That username is taken. Try another.","Errors":{"GmailAddress":"That username is taken. Try another."},"ErrorData":[""]},"Locale":"en"}
From what I can tell, this is a useful first step towards credential stuffing.
Requests against endpoints like this are going to be unauthenticated, since by their very nature they happen before the user is actually authenticated against the system. So you can burn through a few thousand (or hundred thousand) possibles and find out which ones actually have accounts.
From there, you can use one of many other email/password dumps and try authenticating. Hitting an endpoint where you can use an email and password is (hopefully) going to be much more guarded and will start blocking IPs when the rate or variance is too high.
That being said, I don't really know how you can stop the first step. There are plenty of answers here that say you should just let them "sign up" and then send them an email if they already have an account. But what happens if your signup process includes something like accepting payment? Obviously you don't want the user filling out all of that information again.
Wouldn't a similarly effective method be to script SMTP and see which ones get rejected as envelope to addresses?
Email enumeration is often determined to be a UX choice rather than a security issue. I've explored this in the past with the idea of doing this to popular sites to build a demo/psychographic profile of an email address. Had a MVP hosted but not working at the moment. I remember sites included FB, Sephora, Home Depot, CafeMom, ESPN. Most have a XHR call to an API that determines if email exists or a message saying "Your password is incorrect".
I got bored over lunch and made this a node module:
https://www.npmjs.com/package/is-gmail-account-valid
const isGmailAccountValid = require('is-gmail-account-valid')
isGmailAccountValid('some.username', function(err, result){
console.log(err, result)
})Is there something like this for Outlook?
Thanks Google :( I think they should at least put a rate limiter to that endpoint.
I'm going to have to agree with Google here, in that this isn't an exploitable security vulnerability. Knowing that the mailboxes famous.celebrity@gmail.com or controversial.journalist@gmail.com exist doesn't bring me any closer to exploiting the knowledge. I don't know that Famous Celebrity is in fact THE famous celebrity. I don't know whether Controversial Journalist still reads mail sent to that account. Most importantly, I don't learn anything I couldn't have learned by sending messages to every likely permutation of famous.celebrity@gmail.com. This won't teach me anything particularly useful for spearfishing, as I'm just throwing out a net hoping something gets caught.