Against risk-based authentication (or, why I wouldn't trust Google Cloud)
devever.net
devever.net
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".
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?
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.
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.
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.
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.
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
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.
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.
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.
That Google can't imagine a scenario like the one above is maddening.
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.
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.
Also, I agree about risk-based security: it's coming everywhere.
Hopefully you have an iPhone because if you're on android, your phone wouldn't even work.
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.
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.
You know what the problem is, you just refuse to fix it.
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.
It also presents an attack vector to screw up everyone's logins and repeatedly force users to re-2FA every few minutes.
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.
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.
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.
https://cloud.google.com/architecture/identity/single-sign-o...
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.
https://cloud.google.com/architecture/identity/federating-gc...
If you do so, authentication is delegated to AD. And there are other third-party options too:
Using Okta, Google, AzureAD and On-prem AD as your IdP is a reasonable choice. Using all of them is not.
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?
My understanding is your business google account can be impacted by things you do on your personal google account as well.
Trusting google with anything that matters (email etc) is rapidly becoming problematic.
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.
My employee account used to access workspace and GCP was quite different from my personal account.
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.
Admin's having to reset passwords with Google is still rare, because Google asks users to keep their own recovery methods.
Honestly, I can understand the frustration from messing up one's private account access.
But don't blame Google, please.
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.
https://www.paypal-community.com/t5/Managing-Account/How-do-...
What I found out afterwards: using the same mailbox with a suffix ("mailbox+cloudflare@example.com") worked just fine.
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.
[•] 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)
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.
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.
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’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.
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
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.
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.
Maybe this WebAuthn thing will catch on and help? fingers crossed.
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.
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"
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.
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.
>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 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:
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...
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.
Not being able to even access the account is one risk, the product you built your business on getting abruptly sunset is another. [0]
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.