undefined | Better HN

0 pointsmkosmo8y ago0 comments

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.

0 comments

djhworld8y ago

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

mkosmoOP8y ago

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.

Liquid_Fire8y ago

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.

658278y ago

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

j / k navigate · click thread line to collapse