I'm not sure exactly what flow you're hitting, and it's been a while since I've been in any loops about this stuff...
Typically, the phone number use in cases like this is part of trying to prevent bulk operations. If you think about a mass password exposure, there are cases where someone is trying to automate account login when they have access to the password. This is one of many reasons why passwords suck so badly. The solution to this automation is increasingly heavy weight speedbumps, from captchas to phone number ownership. Typically, there is a low limit to how many accounts a phone number can be used for in this context. A similar thing occurs during account creation. So yes, that is less useful for dealing with an individual account takeover, but is useful in aggregate. When I tried to say the same thing on an internal mailing list, I received pushback that this was still 2FA... so, sure, it's a kind of 2FA. That said, it's also possible they've launched a soft-2FA of some kind. In reality, all logins at google are multi-factor, it's just without 2FA, they're forced to use a combination of factors in a complicated manner designed to limit the number of account hijackings. This includes geo-ip, device identification, etc. You are better off enabling 2FA and setting up multiple mechanisms so you're in control of those factors. I think you'd be shocked at the daily number of accounts that have hijacking attempts with a valid password. OTOH, I remember an interaction on the google support forums where we were forcing someone with a compromised password to change their password, and they felt they should be able to keep using the password that was in practically every password dump being passed around because it was their account dammit. As for backup email addresses, I have no idea why that wouldn't work, but it is true that a very large number of backup email addresses, especially for older accounts, are no longer owned. In general, phone numbers are stickier than email addresses for younger folks, but it is also true that in some parts of the world, phone numbers are heavily recycled. As for Google Accounts being abandonware, that's a joke. There is a very large anti-abuse team involved with that, I'd point to passkeys as a huge industry wide effort with a very large contingent of Google work across a number of teams as one big example. There's also huge efforts keeping up with regulations such as DMA and GDPR. Or One Google, which tries to provide higher touch support. Maybe that's all rearranging deck chairs on the Titanic, and a truly distributed authentication system of tens of thousands of providers would do better. That said, there are a lot of websites with their own authentication systems and they get pawned on a fairly regular basis. The status quo here sucks, no doubt about it. I'm not sure what the solution an individual can do is, they can use their own domain, have separation of providers, separation of concerns, store data in more than one place, routine backups of cloud data, but the level of effort to do this realistically is ridiculous and virtually no one does it all. Treating your personal data like a well run fortune 500 company does disaster preparedness. Brandon On Tue, Aug 27, 2024 at 3:35 AM Jaroslaw Rafa via mailop <mailop@mailop.org> wrote: > Dnia 27.08.2024 o godz. 15:26:44 Viktor Dukhovni via mailop pisze: > > > > Welcome to two-factor denial of service. I try to resist signing up for > > such baked-in disasters as much as I can, but the powers that be (hello > > GitHub) have made it impossible in many cases. > > > > It is a sad state of affairs that no opt-out is available for users who > > manage strong per-site passwords, and prize long-term availability over > > often dubious security advantages of said 2nd-factors. > > Google sometimes does it even for accounts that don't have 2FA configured. > I have a Google account (that I don't use for email, but for things like > Google Drive, Google Docs etc.) registered with this very email address I'm > sending this email from. This email is not (and never was) hosted at > Google, > but on my own server. > > 2FA is not configured on this account and never was. Yet a few years ago it > happened to me that when I logged in from an "unknown" device, Google > FORCED > me to add a phone number to my account to send the "verification code" to > this number. Otherwise I wouldn't be able to log in. Which by the way at > that point made no sense, because if it were an impersonator trying to log > in to my account, he could add any phone number, as there was no phone > number configured previously. > > It still happens from time to time that when I login from an "unknown" > device, Google sends a "verification code" to this phone number and doesn't > let me in without typing that code. Despite NOT having 2FA configured. > > Also it doesn't use the perfectly valid email address that is independent > from Google to send this code. As far as I can remember (the last time it > happened was quite a time ago, so I might be wrong), there is an option on > the login screen to send the code to the email address, but I never got it > to work. > -- > Regards, > Jaroslaw Rafa > r...@rafa.eu.org > -- > "In a million years, when kids go to school, they're gonna know: once there > was a Hushpuppy, and she lived with her daddy in the Bathtub." > _______________________________________________ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop >
_______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
