>Firstly, although I don't know exactly what they do these days back when the system was implemented adding 2FA would disable the risk based auth system and make logins purely deterministic, at least after some time had passed (account hijackers liked to add 2FA as the first step in locking down an account after taking it over, so full security didn't start immediately). So unless that's changed he can get what he wants just by using 2FA.
Funny thing, I actually surmised that a lot of services work like this for some time. Interestingly for services the security of which I don't care about and which don't warrant my actually provisioning an air-gapped 2FA token, I often turn on 2FA anyway and just (pointlessly) keep the TOTP secret in the same password safe as the account password.
Why? Because it seems to be treated by a lot of services as a flag to a) disable non-deterministic authentication, and b) as a flag to disable password recovery (or at least make it moot if you can't also recover the TOTP secret). I consider the former actively desirable in all circumstances, and I consider the latter desirable because I have enough confidence in my own credential storage practices that I'm more than happy to accept the risk and responsibility of being locked out if I lose that token.
But this is an unofficial hack. It's not like it's a documented commitment. One basically is crossing one's fingers and hopes that enabling 2FA is some kind of secret trigger to disabling risk-based auth, and I don't really have any way of predicting with confidence whether Google (or any other company doing nondeterministic login) will silently change this later. I want a deterministic login system which is well-documented enough that I can determine ahead of time what set of credentials are sufficient for access.
You are correct that Workspaces makes things much better. I think to address everything in article though, that would need to be combined with documentation as to everything the authentication process can conceivably throw at a user, combined with a firm commitment to an advance notice period before any changes to that process. The discrimination against some browsers also needs to be addressed, for example, is this disabled for Workspaces, and more importantly, does Google firmly commit not to apply this sort of thing to Workspaces in the future?
>Phone numbers
Funny thing. I have an original invitee Gmail account registered 2005 that I can't access anymore because any attempt to login to it causes Google to demand a phone number. There is no phone number associated with the account, rather, it's simply a demand that I give it any phone number, so this can't possibly serve any account security purpose. This seems to me like a raging GDPR violation given that it's essentially an attempt to extort more personal information out of me by holding the account hostage, as well as denying various GDPR rights, like account deletion, subject access, etc. I refuse to use a phone number in general.
>Is it better to lean towards allowing access or lean towards denying access?
You paint a compelling doomsday scenario but the same can be said in another direction. Here's an interesting hypothetical question: if a SaaS (for example) company lost access to all its cloud accounts, but billing kept working and their service was still up, meaning the service still works 'for now' but no changes can be made to it, how long would that company last?
But even this question is a distraction. The real problem here is the lack of legibility of the authentication process, i.e., documentation. I can't predict what the authentication process will do, now or in the future. That's the problem. My best efforts to understand the Google Accounts system (mostly by reading between the lines of how the system works) leads me to the conclusion of this article that I do not have any confidence that it will let me in when I really need it to. That's fundamentally a product marketing and documentation issue more than anything. It could be rectified with authoritative documentation on necessary and sufficient conditions for authentication with a commitment to notification before any changes, at least. It should be possible for me (a non-Googler) to understand the necessary and sufficient conditions for authentication and make my credential arrangements accordingly. But as things stand the system seems to fundamentally lack this property of legibility.
Legibility is important because it gives me the user the power to choose whether I care more about account availability or account security. For example, suppose I enable TOTP on account A. I decide that the lack of availability of access to account A poses more of a risk to me than illegitimate access, so I make three backup copies of the TOTP secret and store them at three separate locations. Since there are three copies, the risk of one of them being stolen is obviously higher than if there were only one. On the other hand, suppose I decide account B poses almost no risk if access to it is lost, but illegitimate access poses a great risk. For this case I might have only one copy of the TOTP secret to reduce the risk of theft.
This is an oversimplified, abstract example but it illustrates how legibility of an authentication system's necessary and sufficient conditions for access allows the user to make an intelligent arrangement regarding whether they want to bias their access towards availability or security. I can't do this with a system which is opaque as to what it's going to ask of me in the future. The system will either ill-serve people whose greater risk lies with lack of availability, or ill-serve people whose greater risk lies with lack of security.
I doubt any company will tie their hands in perpetuity when it comes to security which is by its nature about ever evolving threats. The number of people who are asking for what you're asking for is simply far too small compared to the number of people who expect companies to fight attackers for them.
> it's simply a demand that I give it any phone number, so this can't possibly serve any account security purpose
The purpose of asking for phone numbers like that is to significantly raise the bar for using networks of compromised / spam accounts. Each number can only be used a small number of times to unlock accounts. After its used up, you need to use a different number. Thus this forms a challenge that is very easy for virtually all users to pass (they only need a phone number), but is very hard for abusers to pass because they operate at scale. It means they have to find ways to control large quantities of phone numbers which requires either corrupting phone company employees or large spend on SIM cards and special equipment. You can see what's involved in the photos here:
https://www.bleepingcomputer.com/news/security/ukraine-disma...
https://www.ftc.gov/news-events/news/press-releases/2022/05/...
https://techcrunch.com/2018/09/27/yes-facebook-is-using-your...
https://blog.google/technology/safety-security/an-update-on-...
Still, I hope he'll consider a few factors.
Firstly, although I don't know exactly what they do these days back when the system was implemented adding 2FA would disable the risk based auth system and make logins purely deterministic, at least after some time had passed (account hijackers liked to add 2FA as the first step in locking down an account after taking it over, so full security didn't start immediately). So unless that's changed he can get what he wants just by using 2FA.
Secondly, if you use enterprise accounts via Workspaces then admins can turn off risk based auth or customize it by going to admin.google.com then Security > Authentication > Login Challenges.
Now the author rails against non-deterministic authentication, and suggests just asking users every security question every time. But there are reasons why it's not done the way he suggests. The main one is the unfortunate reality that - as he points out - some small number of users will not make it through the challenges even if they are the actual owner of the account. Therefore every challenge has a risk associated with it and the system works hard to avoid challenging logins if at all possible. It's a last resort option. Perhaps it could run some sort of training challenges which tell the user the right answers if they get them wrong, but:
a. That would make it much easier to phish the answers out of the user.
b. It would be extremely confusing to be presented with something that claims to be ID verification related but which lets you in even if you got the answers wrong. No other system works that way and it would certainly cause a non-trivial fraction of users to conclude the system was broken, or that they hadn't set it up properly (attempting to explain this won't work because a large number of people simply will not read anything put on the screen if it's in any way optional).
So that's why for a long time now all the auth systems of the big tech firms push users to provide a phone number for an account. It's not full 2FA (which can go wrong for users even worse), but risk based auth + a phone number is a dramatic upgrade in security with a very low failure rate, so they'd much rather you do that than try to train you to answer a series of quizzes.
Now why do they do it at all, why can't you opt out entirely? It's because account hacking was a major problem at the time these systems were introduced. I built out the first version of risk based auth at high speed because things were absolutely bananas back then. Account hijacking went overnight from a nearly non-existent problem to being measured in accounts hacked per second. The black market managed to start connecting people with stolen password databases, people with GPUs who could reverse hashes at high speed, people with botnets and people who could use stolen passwords for spamming/fraud to make money. Once those connections got made the quantity of abuse exploded to absurd levels e.g.
https://www.theatlantic.com/technology/archive/2011/04/hacki...
Even if you take a hardline "hacked users deserve it" attitude doing nothing wasn't an option, because the volumes of abusive mails being sent by hacked accounts was at times sufficient to get infrastructure blacklisted by third parties, so the integrity of services were being threatened for everyone. Also, many users couldn't figure out how they were getting hacked and assumed there must be a problem with Gmail.
Finally, there's this core argument:
"Such a system might have good security but it severely lacks availability. For critical infrastructure, this is a disaster."
That's, I think, pretty debatable. If you get hacked that can destroy your business far more effectively than one employee having trouble logging in until an admin can help them. Any security system can go wrong and lock out the real user, including plain old passwords, but there's been a clear trend over time for admins to insist on ever stricter security for high value accounts. Accounts with access to cloud resources are some of the highest value out there.