> I explicitly don't want any non-deterministic, “risk-based” or ML decision involved in a decision as to whether I can access an account which controls critical infrastructure
I don't want this on any account, infra or not. If I can supply my password and complete MFA (TOTP/hardware key) then I want access to my account. I've been in a situation where I was logging in from a known IP, provided the correct password, correct OTP, and had access to the recovery email address on my account, and I was still denied access until I authenticated using a phone number which wasn't even associated with my account. Other people aren't so lucky and simply never gain access to their account again. It's mental. Let me make the decision. Give me a button that says "Always allow access for correct password and challenge".
> authenticated using a phone number which wasn't even associated with my account
As in, they required you to add a phone number when you didn't have one before, or they said "verify you can receive SMS at 555-123-5678" which wasn't even yours?
Yeah they forced me to provide a number during login. I don’t have any numbers associated with my account to protect against sim swapping, and I shouldn’t need a number because I have multiple methods of MFA plus recovery email. But if Google wants your phone number, Google gets your phone number. The number I provided doesn’t appear anywhere in my account but I bet it’s stored somewhere behind the scenes, so they can compare it against previous logins. I do wonder, if I got a new phone number, would it let me in or lock me out?
> There are to my recollection numerous stories of people being locked out of accounts which they have the passwords for because Google has decided that things are suspicious and having the password is not enough.
As someone who used to live/be in different countries on a regular basis, I've become so used to this that I have to remind myself that most users don't experience this regularly. I'm a bit more settled now, but I remember well the first time I saw a 'Can't complete authentication' (or something along those lines) screen, after I had already completed 1-2 extra steps. Not 'Please enable 2FA', not even 'Please use a different browser', simply 'You can't login. Have a good day.'. I've even had this on a work-related account at some point, ie one that's being paid for. Most times you can get it to work after a few days of trying your best to recreate the conditions of the last login (don't VPN to your old location, though, that usually backfires and can cost you a few more days). But I have definitely lost at least one account for good this way. I've literally started to develop anxiety about using Google login forms.
I use my own domain with an email service that I pay for (already since before this started happening) for everything important, and I can't recommend it enough. I know that you don't really "own" your domain either, but my experience with support from a local registrar is pretty good.
Just access gmail using private mode. Every single time, this device is unknown please enter your backup email address to verify who you are, even though your password is 30 chars and complex because you use a password manager.
Google is the absolute worst at this, their 'risk based' login stuff is utter crap, and when you go travelling expect to get locked out and have no recourse because there is no-one to complain to.
Honestly, you would think a multi-billion dollar company could do better, but apparently because its "algorithms", "machine-learning" and a "free service" its okay to be shit.
>Just access gmail using private mode. Every single time, this device is unknown please enter your backup email address to verify who you are, even though your password is 30 chars and complex because you use a password manager.
i have a few "junk" gmail accounts dating back 20 years or whenever gmail came to exist. a while ago i weren't able to login to it, even with backup email addresses/codes. Gmail wasn't sure that me is me and were claiming that all of those emails are under attack
> Google is the absolute worst at this, their 'risk based' login stuff is utter crap, and when you go travelling expect to get locked out and have no recourse because there is no-one to complain to.
I think it is an exaggeration to suggest this will definitely happen if you travel.
I've got mfa setup on my account, work abroad semi-regularly and have never had any issues logging in to my google account.
I moved house within a not particularly far distance and got locked out of one account with a demand for a phone number because the login is suspicious (which I don't trust Google not to use for ad targeting).
This despite having the password and TOTP.
Luckily I had a non-Google email account still connected via IMAP to reconfigure everything pointed at that account.
> As someone who used to live/be in different countries on a regular basis
Not google, but I have never even once been allowed by facebook to login while traveling. So ridiculous. It's my account, I should set the policy.
I don't use facebook much, but the only time I'd care to use it is while traveling to connect with old friends in whichever city I'm in. But no, impossible. I have no use to login to facebook from home, but that's the one and only place I can log in.
One example I can give is from a few years ago. I was in a car crash where my phone was destroyed. It was around 2 AM and I was about 500 meters from my office. I went there to use the stationary office phone to call my wife, but I didn't know her number. I thought I could check my Google account and tried to log in with my personal account. I had never logged in with my account at my workplace before. Of course, Google deemed this suspicious and asked me to confirm with an SMS to my destroyed phone or to open it and click "Allow" in the notification.
The only phone that was not changed in years was my mother's number, and I called her instead because this was the only phone I was able to recall.
After that I moved completely out of google and now I use Nextcloud for my contacts.
You're really describing a more general problem though. Imagine you hadn't been 500 meters from your office. Maybe you're in some city you don't really know and you no longer have your phone. You may not even know where you're staying because information is on the web somewhere.
Google or not, it's a good idea to have generally important information or information pertinent to a particular trip accessible in some way that isn't tied to a phone.
> Google or not, it's a good idea to have generally important information or information pertinent to a particular trip accessible in some way that isn't tied to a phone.
This is what I always do. Print hotel address, general route to the place, tickets, etc. There are too many ways for a phone to become unusable and not knowing where I can sleep is not the kind of stress I want to deal with when in a foreign place.
Many financial institutions and others (including some that aren't obviously sensitive) regularly and randomly want to send you an SMS to confirm your identity.
I now remember both my wife and my mother's phone, but this is a problem with people that are used to their devices keeping that information.
I remember my mother's phone from the time when our house phone was without display and phonebook. Her number is like 20 years old since the introduction of cellular networks. You can experiment and try to recall your brother's or sister's number or cousin maybe? Chances are that you like most people write it in your device and never check even a single digit after that.
What I wanted to describe is not my stupidity that I count on google.
I wanted to describe that I use my account every day to purchase some useless apps in the playstore, but in the most unexpected moment when I needed the account for something a bit serious I was locked out.
I don't want to make this comment long and and philosophical. And it is not rant. Just sharing my view of the story like everybody else.
Oh, you're absolutely right about phone numbers. I know my GF's probably mostly because I've written it in enough times as an emergency contact. But no idea of my brother's or dad's.
You come to rely on a phone, a credit card that works, etc. At least when traveling I've learned to take steps to mitigate the risk when those assumptions fail. But the assumptions sometimes break down in the worst possible way.
You shouldn't trust Google cloud because they'll leave you hanging out to dry. You can get yourself into a situation where your account is locked and nobody at Google will help you get back into your account. Even if you spend tens of thousands a month. There's no way to escalate your way to a resolution with a normal human being, because they care more about what they spend on support than the customer. AWS would never do that.
However, risk based security isn't the problem. Risk based security has been implemented by every major company (interested in security for its users) for the last 15 years. It has nothing to do with whether you'll be locked out of an account without recourse or whether there are alternative ways for you to log in. I used to maintain those systems using middleware. Properly implemented, they're only an inconvenience to a tiny subset of users that constantly use new devices from new locations without 2FA. And you can turn them off for specific users, add an alternative authentication method/criteria, or even fine tune the sensors.
Google's implementation is crap, and the lack of support is dangerous. But risk based security is fine.
Author here. The fact that 'every major company' has implemented risk based security doesn't automatically make it a good or sensible thing. I'm against the premise of nondeterministic login processes in general, not just for Google.
I will also say that the idea of detecting users which login from "new devices" is nonsense, at least if you're talking about a webapp. There is no such thing as a "device" as far as the web is concerned, in fact massive amounts of effort are invested into web browsers and web standards to try and prevent any kind of fingerprinting. The web platform very intentionally does not give webapps any way to identify or remember a "device".
So what "you're logging in from a new device" actually amounts to is, "you deleted the permanent cookie we tried to set". Which in my case always happens because I have cookies set to be deleted the instant the last tab from a given origin is closed. Sure enough, these sites doing this irritating 'new device' authentication incorrectly think I'm logging in from a 'new device' all the time. Reminds me of cookie popups that ironically can't be disabled when a user has cookies disabled because they use cookies to remember that they've been shown. In both cases the user is penalised for being proactive with their own privacy.
A user agent that refreshes parts of its profile at the end of a session and deletes data, hopefully, should be something a company like Google can pick up on after enough attempts. "We can't expect the nonexistence of a persistent cookie means the user is using a new user agent because of a persistent history of successful authentication attempts without such cookie present" is not a tall order for a company like Google who is running these experiments on their users.
It is odd you are pathologizing what I would expect to be normal behavior. It's not common behavior, but it doesn't seem abnormal for user agents to do this.
Edit: for users who only access their Google accounts via shared machines like at a public library, not having a persistent cookie on every auth attempt is going to be the expected scenario.
I agree that public library access for people who don't own a computer is an important and difficult problem, but you're talking about other people, not the case being discussed now. Bringing it up here is a distraction.
For someone who is tech-savvy and owns a laptop, there is a simple solution: create a new, vanilla browser profile and use it only for logging into Google. (I do the same thing, but for Facebook.) You'd don't need any privacy extensions when you want them to know who you are.
Bringing it up here isn't a distraction, it's central to my main point: the workflow of having a user agent refresh its persistent state is an expected use case, and therefore signal analysis should understand that for some users, the non-existence of a persistent cookie is no indication of elevated risk above baseline.
User agents are remarkably easy to spoof at scale. Bad actors could cycle known user agents with a password until they hit the right non-2FA login agent.
It also presents an attack vector to screw up everyone's logins and repeatedly force users to re-2FA every few minutes.
I don't understand some of the ways you are using terms e.g. when you say "user agent" it sounds like you mean the User-Agent HTTP header, which is trivial to spoof, but that isn't how I'm using the word user agent, which I'm saying means the agent that a given user acts with.
I also don't quite understand your threat model here and the details of what you're proposing is an attack. If you are a user who Google consistently knows has a persistent cookie at auth time, Google can expect that in the future and therefore use that as a data point in risk based authentication. If you are a user who Google consistently knows doesn't have a persistent cookie at auth time, Google can't rely on that data point providing any signal in risk based auth, and seems to be DoSing, or at least frustrating, users in that scenario.
I can't quite respond to your comment because I don't fully understand it.
> You're logging in so they know who you are, but you refuse to keep a cookie in your browser so they won't know who you are?
The two sentences are not in contradiction at all. As long as he has the credential (password and perhaps 2FA), he should be able to log in. The cookie is a convenience, and should not be a requirement.
Users typically use the same browser on each device, so using first party cookies to identify a device for web logins is not that far fetched of a solution.
Same exact thing has happened to us. Real company, real customers. Locked out of account entirely for 4 days with no response from the team, no apology, no explanation. Buyer beware. We’re planning on migrating to AWS once we can get a confirmed allocation of H100 GPUs (springtime) for our DL stack.
This seems...wrong? I spend tens of thousands a month on GCP. If we were somehow locked out I would immediately raise hell with my account manager. Who is spending that kind of money and doesn't have one?
You wouldn't be able to contact your account manager as your google account would be suspended and emailing from another address wouldn't elicit any response (even if you could remember your account ID/contact info).
Hopefully you have an iPhone because if you're on android, your phone wouldn't even work.
Thinking out loud from a DR perspective, I would directly call or email my account manager. Issues like that are direct contact, you don't go through a central support system.
Worse case scenario, if my Workspace account is somehow locked, that would only impact the work profile on my Android phone. If I somehow lost access to his phone number, I have him on LinkedIn.
If all of those fail, I would contact the Google office he works out of.
Try asking your account manager to get you into a Google Workspaces account you can't verify the challenge questions to and don't have admin access to, even though it's literally linked to the domain that you own and control in GCP. They just send you to support and support can't help you. They don't need our business apparently.
The other day I used an authenticator app for my second factor. It was successful as far as that goes but it still wanted to verify that it's me by sending a prompt to my phone. I don't call this security. This is abuse.
You're misunderstanding the above post and conflating it with a MFA authentication method. If you use another authentication provider, Google does not authenticate you at all - your provider does (Okta etc).
You're right it's a weak answer to that but I was aware of what's being said. The example was for the arbitrariness of the whole thing. The same Google could easily decide to drop a provider or force their own again etc.
Dropping SSO support would mean losing a lot of enterprise customers. Forcing organizations that have chosen Okta or Azure AD as their identity solution to either get separate Google accounts or sync their directory to Google, would not be easy at all.
For those who are worried about their accounts, I would recommend setting up Google Advanced Protection Program [1]. It will ask you for a physical security key and I didn’t come across any other checks while logging in (i.e. random checks the post is talking about).
> Only app installations from verified stores, like Google Play Store and your device manufacturer’s app store, are allowed.
This part is absolutely unacceptable and it is, again, treating users like incurable idiots. I trust myself much more than anyone else in this entire universe.
I also don't see how this approach can possibly survive the upcoming EU platform regulation. In the context of the DMA, "You can use third-party app stores only if you deactivate account takeover protections" seems like a non-starter.
And I wouldn't turn it on without at least three keys (one of which can be your phone) -- the consequences of accidentally getting down to zero are too high.
On a slightly related note AWS just recently forced me (and probably everybody else) to separate Amazon shopping credentials from AWS credentials. I had never liked that they were common.
New AWS accounts were already being created without associating with retail logins. It's just now that they forced this migration out of Amazon.com for old accounts.
So if I'm serious about using GCP, I also need to use an Azure service? And now I understand why most companies either choose to use AWS or stick with Azure (despite its limitations).
Of all the reasons to choose AWS over GCP, account management would NOT be one of the ones I would consider. Amazon's account management is a fucking nightmare. I basically just don't login to Amazon anymore because it's so broken.
Indeed, they mention having had an account "10 years". I can only assume this means they are using their personal account for GCP which other than some hobby projects is not something any business should be doing.
You wouldn't have your employees using their personal email accounts for your business communication, why would you use them for their infra/services login?
Using google does seem to have become a russian roulette, especially considering that the next step - reaching out for support - has also been ML-ified and one is reliant on support via hn/twitter.
Trusting google with anything that matters (email etc) is rapidly becoming problematic.
Exactly. Nobody should be trusting Google with anything. Period. Between them reporting their users to the police and refusing to back down even when forced to publicly address their mistakes, their issues with 2FA/recovery codes, data-mining everything you host with them, etc, I don't know how anybody could ever be comfortable trusting them with their data.
Imao, zero-trust is the ideal, and Google is infinitely contrary to that standard no matter what way you look at it. I can't see a single positive to their "value" proposition unless you are an data exhibitionist who wants to pay a panopticon to disseminate your entire life to hungry marketers and throw you to the wolves the moment their ML/AI makes a non-discretionary case against you.
This article puts consumer accounts, enterprise accounts and what we call robot accounts in the same bag, but the reality is that the three classes of accounts have different authentication and authorisation processes and the risk evaluation is quite different.
Author here. A bit confused by this comment since I make this exact point in the article. The requirements for 'consumer' and 'enterprise' authentication aren't the same, yet they're forced to use the same system in Google's case.
As a business user of Google Workspace, it is a very different situation. Any one of our Super Admins (we have 3) can quickly unlock an account of any employee that has been locked out. We can also adjust the sensitivity of the auto lockout. For example, we currently get notifications of "suspicious" logins but do not auto lockout the user.
That seems great for expediency, but it also seems to place the exposure to social engineering back on the org, who might not have the best tools to authenticate someone whose account is already in lockdown.
For example, I'm a remote user, and if I got logged out of all company systems, I could phone my supervisor or send email from my personal account. Is that enough to assure the Super Admins that I am who I say I am?
Our employees can only access the Google Workspace from managed devices and everyone is required to use 2fa.
If your account is flagged for a suspicious login, we call you. Unlocking your account only allows access from your assigned managed devices. If you have forgotten your password or lost your 2fa token and/or managed device, you have to come to the office in person.
No. You can use Google's consumer systems if you want to, and will do so if you log on with your Gmail (consumer) account, but GCP will happily talk with "enterprise" Workspace orgs, Active Directory, Okta, etc.
Yes, it seems like the groups thing isn’t so baffling if you realize that Google groups is also the way groups are created and managed in the g suite (google workspace) system. So it seems less looney that you would use those groups, which likely already exist and are managed by HR, for things like Sysadmins or “EU NOC Support Staff” or “IT Managers” for GCP permissions as well. I agree that outside of the Google workspace ecosystem this becomes a weird quirk but honestly, I would be kind of surprised if that many sizable customers of GCP aren’t already on the G suite too since G suite has much greater share in its market than GCP does.
Not just Google. Recently I tried to web login to my PayPal account. PayPal decided it was a risky attempt for some reason and asked me to provide a phone number for verification. So I gave it the one associated with my PayPal account for years, and it refused! Presumably because the number was a virtual one, which I used for all account registration stuff in case of switching carrier or out of cell coverage.
I was locked out of my account for several days due to the phone requirement until it clicked for me one day: maybe I could try login with the PayPal app on my iPhone? Sure enough, PayPal trusted the app and let me login to their app. Then I tried to web login again, and this time it asked me to confirm in the mobile app that it was indeed me who's attempting the web login.
Given that PayPal is handling people's money and they have good reasons to be cautious, but risk-based auth really sucks at times when you don't have enough patience for it.
I have to second this. Google products are dangerous. As an example, Gmail once silently dropped all emails to or from my email account - they didn't bounce back with an error message, they vanished in a black hole. This took me a while to figure out and it caused substantial damage at work. It took my commercial email provider several days to get Google to fix the problem. Their support staff told me they weren't able to contact any person at Google, they had to fill out a web form.
We had that happen with Cloudflare-forwarded emails on a specific mailbox. I wrestled with CF's support until I got to someone who was able to debug the issue and they found out that everything was sent successfully and accepted by Google's servers, it just vanished afterwards.
What I found out afterwards: using the same mailbox with a suffix ("mailbox+cloudflare@example.com") worked just fine.
The clearly problem is to make a good providers/products, you need good product managers and product operation teams, mostly this is not tech related. So from my view, Google is never a good provider.
As a former Gaia Admin, there's actually a lot more to Google Groups as the source of auth truth; In fact, I would describe it the other way around. Google Groups is an authentication system that happens to have a mailing list feature, though I'll definitely say that the UI is fairly bad for both.
I will point you, though, to the fact that Active Directory works exactly the same way, and has exactly as bad an interface for both. It's like there's a natural local maximum these products get stuck in, because there's no reasons to build two interfaces for the same product, even though it's used two very different ways.
This is not entirely unique to Google either. I have an old MSN email account I can't get into even though I know the password. It wants me to verify via an old phone number I no longer have access to.
I experienced this with my Google workspace account’s access to YouTube. I have 2FA set up using TOTP[•], it works fine. I can also log in to our work YouTube channels, but whenever I try to manage users on any channel, I get blocked. No re-auth option, nothing, just not allowed. Even from the same device and IP that I’m logged into for months. Support wasn’t able to resolve this yet.
[•] To enable TOTP I had to first add a mobile number as 2FA, then add TOTP (Google authenticator) and then remove the number (I did not want to use my personal number for work)
Related unhelpful behavior of Google's auth system:
Dropping you from an online meeting, mid-meeting, and demanding you log in again right now. Perhaps because it had been X days since you last logged in or whatever.
I don't recall experiencing it recently, but it happened a LOT in 2020 and 2021.
It's not just Google. My wife's wallet was stolen recently while we were out of town, leaving us with a single uncompromised credit card with which to get through the rest of the trip. A few days later, I got a call from the credit card company asking me to contact them. Apparently they thought there was suspicious activity on this card. I have email notifications enabled for all my cards so I knew that all the recent transactions were legit, and so I called thinking that all I would need to do was confirm that.
When I called, they started asking me a bunch of weird questions about previous addresses in order to verify my identity. I have been at the same address for 12 years. It turned out that they had contracted with a third party to do identity verification, and this third party had incorrect information. But of course they would not tell me who the third party was (I still don't know) or how I could get the mistakes fixed. I was unable to authenticate myself to their satisfaction, despite the fact that I had access to the on-line account and I could tell them the date and amount of every single transaction on the account. I was livid because I was convinced they were going to shut down the account, leaving me with no working cards several thousand miles from home.
Fortunately, they did not shut down the account. Instead, they mailed me a physical letter with a four-digit PIN, which I was able to used several weeks later to authenticate myself and get the account cleared. I never found out what happened to get the account flagged in the first place.
Since then my wife and I have reviewed our security processes and in addition to having half a dozen backup cards (no exaggeration) we now make sure that we never keep more than three of them in the same physical location in order to avoid a repeat of that situation.
I'm a little surprised there aren't more horror stories about people getting stuck in places if their wallet gets stolen on a trip. We got very, very lucky that not all of our cards were in my wife's wallet.
I reject the use of surveillance based authentication. I do not consent to my information being used in this way, nor it being stored in those surveillance databases in general. And I certainly do not want to confirm their records.
When confronted with it, I generally answer the questions without using any personal knowledge - either choosing none of the above or doing web searches for questions like what city is Foo St in. This works about half the time (demonstrating the uselessness of it), and the other half they can just send me a snail mail letter.
(Of course this isn't really applicable to the situation you found yourself in, and I could see myself making the same compromise under duress. But speaking generally)
I had a similar issue with PayPal a few months ago.
I’m not sure if it was a bug or its risk-based authentication being inane. But my 2FA options were limited to SMS for several weeks, even though I had software and hardware token 2FA enabled on the account.
This seemed to have resolved itself recently and I can use all my 2FA methods again. But it was certainly annoying and I wonder if it was PayPal pushing too hard that it didn’t consider software and hardware tokens legitimate methods of verifying my identity under certain conditions.
For everyone complaining about lack of support from Google Cloud and the possibility of being locked out: make absolutely sure you have more than the free support plan otherwise even your account manager can’t do anything.
Your Google identity is supported by the GSuite or Workspace organisation and not Google Cloud. They will provide absolutely zero support unless you pay for support.
Source: close friend who works at Google Cloud who has been unable to help customers
Asking authentication service to not use risk while using phishable authentication methods is essentially asking them to not bother with any protection from phishing and various password and 2nd factor theft.
If you don't like risk-based auth, use non-phishable authentication method like security keys.
Note that false negative (letting attacker steal) is roughly equivalent as false positive (not letting actual owner access the account) from the owner's access since the owner can't access the account in both cases (most attackers try to take over the account and lock out the original user - if you are a target of sophisticated attackers who would silently steal and watch your information, you wouldn't complain about risk based protection). But the former is worse from privacy obviously, thus any sane provider tend to choose false positive over false negative. The only way out of this bind is to use non-phishable auth, and at this point, security key is about the only one, with app based notification being close.
> asking them to not bother with any protection from phishing and various password and 2nd factor theft.
Yes, so? I can deal with phishing myself, especially with TOTP 2FA that risk is far far smaller than the risk of being locked out by some dumb risk heuristic.
If the general public can't be trusted, fine. But let me disable these extra "protections"
The browser won't help you avoid putting it in the login form at google.com.fakehackersite.com which can then just relay that to real google.
I think this is still an improvement over SMS, and personally is something that risk wise I'm happier with than the idea that if I lose a yubikey or it breaks down it's game over.
Ah, i see. definitely a concern for if i were administering an org. I still like TOTP vastly better than the only alternative with wide reach, the dreaded and stupid "code sent via SMS" but I hear you on the risk with unsophisticated users who click things.
Maybe this WebAuthn thing will catch on and help? fingers crossed.
> I hear you on the risk with unsophisticated users who click things.
The evidence says this attitude of "it's other people who get phished and not me" is pure arrogance. Practically all sophisticated security professionals can be phished with sufficiently sophisticated attacks, if the underlying system is using a phishable credential.
Just something to note: This concern doesn't apply to companies that pay a lot of money and have a tam or "customer success *" person assigned to them who they can call and get things done. All the lockedout complaints are from individuals or small or medium-small (<2k) size companies. I only say this because while I don't have a single google device and haven't used a google account in years personally, I have no problem using gcp stuff for work where we have federated login plus multiple contracts with them.
When you have a contract with them, you can sue them for downtime/costs resulting from faulty lockouts. Even if they expressly made you sign that you can't, you can still have merit and your day in court with a good legal team and they know it.
> Fundamentally, the accounts system is clearly consumer-oriented. A lot of this risk-based authentication seems based on the general premise that most users of the Google Accounts system can't really be trusted to set secure passwords and are their own worst enemies.
> This attitude... might be true for consumer accounts
I don't think this attitude is any less true for "GCP accounts". Maybe you can trust yourself to maintain password security, although, I would suggest that you might want to be a bit more humble. In any case, once you have other developers on your team, you'd be insane to trust them all to maintain password security.
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:
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.
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.
Thanks for responding, as this offers some interesting perspective.
>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.
> this is an unofficial hack. It's not like it's a documented commitment
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 it's 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:
I suppose it does raise the bar somewhat, but there are many websites that sell access to phone numbers that specifically work on major services like Google for as low as 10 cents per text.
If you regularly change countries, you might want to rent a VPS with stable IP address and use a VPN. This way your IP address will not change and Google will not raise alarms.
Using datacenter IP address might be alarm by itself, though. So the best way is to build a route to your home router, but that might be tricky.
Google has a reputation for being especially bad with this sort of thing but I tend to see it as a distinction between the underlying infrastructure being based on classic tools vs crypto. Doing things the old fashioned way you run into this kind of risk. Google turns off your account, or somebody sim swaps you for your 2FA, or you wake up to find your account deleted but you never find out why.
With crypto those types of risks systemically don't exist in the same way. You get new sets of risks like losing your private key, or someone stealing all your crypto with no recourse, or misconfiguring things so that when you try it 6 months later it doesn't work.
Both approaches have tradeoffs. Any time I see something like this though, the idea of using systems that are backed by some kind of dumb blockchain and api rather than a dumb AI filter does appeal.
I don't want this on any account, infra or not. If I can supply my password and complete MFA (TOTP/hardware key) then I want access to my account. I've been in a situation where I was logging in from a known IP, provided the correct password, correct OTP, and had access to the recovery email address on my account, and I was still denied access until I authenticated using a phone number which wasn't even associated with my account. Other people aren't so lucky and simply never gain access to their account again. It's mental. Let me make the decision. Give me a button that says "Always allow access for correct password and challenge".