zlacker

I may be mis-understanding, but it sounds like this kind of widely distributed attack would also be stoppable by checking how often the account is attempting to log in? And if they're only testing two or three passwords _per account_, per day, then Google could further block them by forcing people not to use the top 10,000 popular passwords in any of the popular lists (including, over time, the passwords provided to Google)?

>>svieir+(OP)
The attackers only try one or two passwords, that they hacked/phished. They aren't guessing popular passwords, usually they know the correct password for an account and would log in successfully on the first try. There are no server side signals that can be used to rate limit them, especially as the whole attack infrastructure is automated and they have unlimited patience.

>>mike_h+eb
Forgive me for being reductive, but aren't these leaked accounts a lost cause? The vulnerability in question is attackers being able to log into user accounts with leaked credentials. The only mitigation for this is to lock out users identified in other password breeches and reconfirm identity out-of-band, like through a local bank branch, add a second factor like a hardware token, or use restrictive heuristics like IP geolocation consistency between visits.

If 3 attempts per hour is enough to gain access, then it doesn't seem attestation can save you. I imagine a physical phone farm will still be economically viable in such case.

>>pona-a+EJ
Yes that's what companies do. I worked on the system there that addressed this. If you can detect a botted login you can lock the account until the real user is able to get new credentials, or block activity in other ways. Not a lost cause at all.

It was very effective when this problem was new. Don't know about the current state of things.