Although I didn't work there for a long time now about 12ish years ago I started the risk based authentication project at Google, so if Hugo wants to blame someone specific I'm here and ready to take some arrows:<p><a href="https://blog.google/technology/safety-security/an-update-on-our-war-against-account/" rel="nofollow">https://blog.google/technology/safety-security/an-update-on-...</a><p>Still, I hope he'll consider a few factors.<p>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.<p>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.<p>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:<p>a. That would make it much easier to phish the answers out of the user.<p>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).<p>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.<p>Now why do they do it at all, why can't you opt out entirely? It's because account hacking was a <i>major</i> 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 <i>accounts hacked per second</i>. 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.<p><a href="https://www.theatlantic.com/technology/archive/2011/04/hacking-epidemic-no-joke-lock-down-your-gmail-now/237375/" rel="nofollow">https://www.theatlantic.com/technology/archive/2011/04/hacki...</a><p>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.<p>Finally, there's this core argument:<p><i>"Such a system might have good security but it severely lacks availability. For critical infrastructure, this is a disaster."</i><p>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.