- 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.
I already said they could have done more. They could have forced MFA.
All the other bullet points were already addressed: they used a botnet that, combined with the “last login location” allowed them to use endpoints from the same country (and possibly even city) that matched that location over the course of several months. So, to put it simply - no, no, no, maybe but no way to tell, maybe but no way to tell.
A full investigation makes sense but the OP is about 23andMe’s statement that the crux is users reusing passwords and not enabling MFA and they’re right about that. They could have done more but, even then, there’s no guarantee that someone with the right username/password combo could be detected.
I’m not sure how much MFA would have mattered in this case.
23andme login is an email address. Most MFAs seem to use email as an option these days. If they’re already reusing passwords, the bad actor already has a password to use for their emails that’s likely going to work for the accounts that were affected. Would it have brought it down? Sure, but doesn’t seem like it would’ve been the silver bullet that everyone thinks it is.
It’s a big enough detractor to make it cumbersome. It’s not that easy to automate pulling an MFA code from an email when there are different providers involved and all that. The people that pulled this off pulled it off via a botnet and I would be very surprised if that botnet was able to recognize an MFA login and also login, get the code, enter it, and then proceed. It seems like more effort than it’s worth at that point.