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.

To verify the existence of a single account all you need to do is go to gmail.com and attempt logging into it. It's that simple. Sometimes you will even see the profile pic so you know who this user is or claims to be.

The OP found a way to discover 40000 new addresses of random people per day by brute forcing through a dictionary-generated list of plausible candidates.

Use it for Nigerian scams, Viagra ads, account hijacking, anything you please.

This feature really grinds my gears. They should at least allow a feature to disable showing the picture/name until the user has logged in. In some cases I'm handing out my email to avoid handing out my actual identity because I don't want to be spammed or followed. Until then I will continue to use a false name and photo under my accounts signed up to google (apart from the one work email I have thru them).

AFAIK the picture is only shown if Google is reasonably confident that it is actually you trying to log in.

> AFAIK the picture is only shown if Google is reasonably confident that it is actually you trying to log in.

I didn't know about this feature, but I often saw pictures of people I know when I tried. Apparently, it seems that for example just sharing IP address is sufficient to trigger this reasonable confidence. Not sure what other ways there may be. But indeed, it didn't work for a few random strangers from LKML I just tried.

IP is a factor, but it's actually much more sophisticated than that :)

Thank you for this information - seems to be so - just tried a VPN from Canada and it only shows the email that I entered. However I still would like to disable it on the off chance that someone in the future messes up. May never happen but I'd like to not take that risk. Thank you none-the-less as that has eased my mind a little bit.

Sounds like a SAAS - verify emails from gmail, hotmail, etc...

With as many accounts on these services that actually exist, it still doesn't answer the question of whether or not the person actually owns the email.

>Sometimes you will even see the profile pic

if it was your account

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.

Do the same thing on the signup page: If the email is already registered just progress the same way - send an email to that address and notify them that they already have an account.

Which is great for most accounts, but what about a primary?

How do you sign up for Gmail without an email account in this case?

well, obviously this will not work for a primary account. It also adds friction the signup process, leading to lower conversion rations. But for some use-cases that may be a valid trade-off. Think dating sites, ..., stuff where knowing that a certain email is subscribed already may be embarrassing or worse (gay dating websites in certain countries).

Oh absolutely, it's a good system and many sites already utilize it.

I only mentioned the Gmail example because that's what the article was about, it sounded like you were suggesting a solution for that scenario.

Use your shudder isp-provided one. Hello IAmBindingMyselfUnnecessarilyTo@comcast.net

ISP email or any provider that doesn't ask for a secondary account, like Mail.com.

This is actually not difficult to address. Modify the account creation process so that the first step is to enter an email address. If the account does not already exist, an account activation link/code is sent. If it does, a password reset link/code is sent.

> If the account does not already exist, an account activation link/code is sent.

That's not great for all use cases, though - if I'm just trying to check out of a store, I don't want to have to bounce to my email to confirm stuff.

If you're just trying to check out of a store, you don't have to sign up for an account at all. Or if you do want to create an account, you can have it as an optional step after you've placed the order.

yeah but which signup form doesn't have a rate limit?

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.

> I've never seen anyone else acknowledge "confirmation of email address existence" as a security issue

It's usually called "username enumeration" and there's plenty of pen testing firms that include this as a standard part of their process.

How do you prevent username enumeration when you want to have a username taken feature in the sign up process? I suppose a way to handle that would be to throttle the number of times such an IP can make those requests per month or something. This still will not prevent a motivated attacker, or the casual use to check if one or two usernames are registered.

In most cases, you can use an email address as the account name, and send a confirmation email containing a link they can use to sign up.

If the account already exists, you send an email saying something like "Hey, you tried to sign up but you already have an account. If you need to reset your password, follow this link." If the account doesn't already exist, you send the normal "follow this link to confirm your account" email.

From the attacker's point of view all they get told is "Check your email to continue" whether or not the account is already registered, so it doesn't leak this information.

This isn't always suitable – a mail provider like Gmail is an obvious example – but it would work for the vast majority of websites / web applications.

To be honest, I don't really rate username enumeration as a severe problem for most projects – obviously it's a problem if you can determine whether an email address is registered on, e.g. Ashley Madison or similar though. But it's simply not the case that "nobody else acknowledges it as a problem" – it's a very widely used test, even if the severity is usually considered low.

Username enumeration is useful against a system with 10 or 1000 accounts, but absolutely meaningless on a system with 1,000,000,000 regular users.

It can be useful in either case. It depends on what the attacker is trying to achieve. If they just want to get in as any user, then your hypothetical system with a billion regular users is going to be even easier, because if even a fraction of those can be enumerated, it's likely that at least some will be accessible using a password-spraying attack using one or two common passwords, or by cross-referencing with passwords disclosed in a breach.

But if we're talking concretely about GMail here, the easiest way for someone to get in as "any user" is to create a GMail account.

> I've never seen anyone else acknowledge "confirmation of email address existence" as a security issue

Every guide to setting up an email server starts with "turn SMTP verify off if your server has insecure defaults"

There's a difference between being able to do that 10 times or 40.000 times in an hour.

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"}

See: https://gist.github.com/saml/2268291

Checked and it still works too. Ported to node and added to: https://github.com/mikemaccana/is-gmail-account-valid

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?

Sure, but I imagine there is some form of rate limiting on that, whereas the point of the article is that they found an endpoint without rate limits.

There might be a rate limit, but it's definitely possible to use this method and get higher than the ~40k a day that the author attained.

Nope, it doesn't do that.

  >RCPT TO: <someaccountthatdoesnotexist@gmail.com>
  550-5.1.1 The email account that you tried to reach does not exist. Please try
  550-5.1.1 double-checking the recipient's email address for typos or
  550-5.1.1 unnecessary spaces. Learn more at
  550 5.1.1  https://support.google.com/mail/?p=NoSuchUser j63si2824869ybj.160 - gsmtp
  >RCPT TO: RCPT TO: <john.baker@gmail.com>
  250 2.1.5 OK j63si2824869ybj.160 - gsmtp

Ah! You're right, my bad, I was thinking about VRFY command!

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".

That is very interesting! I wonder if some companies already doing that to "qualify" email addresses for sending spam, or more ethicaly enhancing their own email lists with this.

e.g. checking if my customers use competitors

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?

Nah, it's not a security bug, that means we can exploit it.

Makes me wonder what they require to classify the bug as a security bug. Perhaps it gets classified otherwise since there's no data leakage other than an address? The existence of an address isn't exactly confidential.

I guess the authors idea of

1. Checking if an email address exists

2. Running it against a known dump of leaked data, with passwords etc

3. Try logging in to google account with the leaked password, hoping the user reuses passwords

Google encourages their users to use 2FA and has other measures to detect when logins are coming from unknown locations, so I guess they figured the risk of this was pretty low

Agreed, a popped account is a bad thing, especially if it's published as such. A larger risk would be somebody popping one of the compromised-credential repositories. Then you've got both username and password. But here we're effectively seeing a slow-scale brute force...

Everybody should enable 2FA, and use the strongest 2FA you can. Buy a yubikey or other U2F key and use it for everything possible. And webdevs, please start supporting U2F in addition to RFC 6238 TOTPs. It's really not that hard.

If you have a leaked database dump with login details, you already have the email address in the dump. You don't need to exploit this to find it.