- cross-posted to:
- hackernews@derp.foo
- cross-posted to:
- hackernews@derp.foo
Hope this isn’t a repeated submission. Funny how they’re trying to deflect blame after they tried to change the EULA post breach.
Hope this isn’t a repeated submission. Funny how they’re trying to deflect blame after they tried to change the EULA post breach.
IP-based mitigation strategies are pretty useless for ATO and credential stuffing attacks.
These days, bot nets for hire are easy to come by and you can rotate your IP on every request limiting you controls to simply block known bad IPs and data server IPs.
The attackers used IPs situated in their victims regions to log in, across months, bypassing rate limiting or region locks / warnings
I don’t know if they did but it would seem trivial to just use the tokens in-situ once they managed to login instead of saving and reusing said tokens. Also those tokens are the end user client tokens, IP locking them would make people with dynamic IPs or logged in 5G throw a fuss after the 5th login in half an hour of subway
Yeah 2FA should be a default everywhere but people just throw a fuss at the slightest inconvenience. We very much need 2FA to become the norm so it’s not seen as such
I’m cool with 2fa, I’m not cool with a company demanding my cellphone number to send me SMS for 2fa or to be forced to get a 2fa code via email…like my bank. I can ONLY link 2fa to my phone. So when my phone goes missing or stolen, I can’t access my bank. Only time I have resisted 2fa is when this pooly implemented bullshit happens.
Pro tip, when making a new Google account and putting your phone number in be sure to look into more options. There is a choice to only use it for 2fa and not for data linking.
2 factor beats the hell outta that “match the horse with the direction of the the arrow 10x” bs