Item — HN Reader

This is not a "leak". All of these email addresses were already in the wild. The "attacker" simply tested if Coinbase accounts matched these emails.

Think about it. Email enumeration is possible if accounts associated with an email address. Otherwise forgot password forms would simply say successful even if someone typo'd their address (terrible UI) or the signup forms would allow multiple accounts with the same email address.

2 comments

Actually, many password forget forms do not provide any information about whether the email was recognized or not. More than once I've seen a message along the lines if "If the email entered was associated with an account, a password reset has been sent.".

EDIT: On the other hand even if the response is always the same, I expect most implementations to be vulnerable to a timing attack ;)

How would they be vulnerable to a timing attack?

Sending an email takes more time than not sending an email.

I think I see your point; clever. The site could show the message and only then send the mail asynchronously. I guess that's why you said most implementations.

Queuing up an async message still takes time. As does reading a row from a database and materializing an object. So "most" is really probably nearly all unless they take explicit steps to make sure the same amount of work is performed in either case.

Yes, or sleep to elapse a time that's longer than needed to queue up the async message, say half a second, before returning the message to the browser.

While that could be true, this list also includes the names; which would not be possible from what you're describing.

If you put in an active email, it sends back the name through the API. Similar to the way that snapchat API bug sent back a username with a phone number as input.