Hacker News Reader

Comment by therealmarv | Hacker News Reader

Thanks Google :( I think they should at least put a rate limiter to that endpoint.

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.

I mean it's pretty much "does a shitty engineer look at this ticket or not", like most large companies.

Reply on news.ycombinator.com