Comment by quacksilver
4 months ago
I do web app testing and report a similar issue as a risk rather often to my clients. You can replace Google below with many other identity providers.
Imagine Bob works at Example Inc. and has email address bob@example.com
Bob can get a Google account with primary email address bob@example.com. He can legitimately pass verification.
Bob then gets fired for fraud or sexual harassment or something else gross misconduct-y and leaves his employer on bad terms.
Bob still has access to the Google account bob@example.com. It didn't get revoked when they fired him and locked his accounts on company systems. He can use the account indefinitely to get Google to attest for his identity.
Example Inc. subscribes to several SaaS apps, that offer Google as an identity provider for SSO. The SaaS app validates that he can get a trusted provider to authenticate that he has an @example.com email address and adds him to the list of permitted users. Bob can use these SaaS apps years later and pull data from them despite having left the company on bad terms. This is bad.
I think the only way for Example Inc. to stop this in the case of Google would be to create a workspace account and use the option to prove domain ownership and force accounts that are unmanaged to either become managed or change their address by a certain date. https://support.google.com/a/answer/6178640?hl=en
Other providers may not even offer something like this, and it relies on Example Inc. seeking out the identity providers, which seems unreasonable. How do you stop your corporate users signing up for the hot new InstaTwitch gaming app or Grinderble dating service that you have never heard of and using that to authenticate to your sales CRM full of customer data?
You don't need full blown workspace, which costs money, you can set up "cloud identity free" and claim the domain.
When you're setting it up, you can choose what to do with any existing accounts that are part of your domain: kick them out or merge them in.
This is the right answer for this problem. If you're not interested in being a paying workspace customer, get cloud identity free and verify your domain. You can then take over and/or kick out any consumer users in the domain.
Every time I've left an organization, they have swiftly deleted the company email address/revoked my access to it. I assume every reasonable organization will have processes in place to do this.
I don't see this as a vulnerability: how is Google supposed to know that a person has left the company? You let them know by deleting the account.
In the above example, the Company doesn't have anything to do with the Google account that the user created themselves.
I don't know if Google is the best example here. Apple might be a better one:
1. User's work email is user@company.com
2. User creates Apple ID using their work email. Their Apple ID is user@example.com
3. User gets fired and their company email is deleted
4. User can still sign in to the SaaS apps using SIWA and their "company" Apple ID
It's worth noting that OAuth providers - like Apple - include information such as if they are authoratitive or not over a particular account.
In the above example, the normal flow to get a Google address user@company.com relies on setting DNS records for company.com, both to prove control of the domain as well as to route email to that domain. There may be an exploit/bypass I'm not seeing, but I legitimately don't see any way a user who has a legitimate user@company.com email address hosted somewhere besides Google workspace could then setup a user@company.com email address with Google.
If there's a way to do this, I would greatly appreciate a link or brief explanation, as our process for employee termination/resignation does involve disabling in the Google admin portal and if we need to be more proactive I definitely want to know.
3 replies →
The example states that the user works at Example Co and email is @example.com
This is the confusion — it’s reasonable to assume that the email is not a personal address.
That removes you from their system. If I make a GitHub account using bob@example.com, GitHub doesn't get notified that I got fired from example.com, so I can keep using my GitHub bob@example.com account in places that ask GitHub if I'm Bob@example.com even though I don't have access to that email anymore.
This no longer happens for services that have accounts that follow a social media style. For such accounts, employees are expected their own accounts (presumably with followers, reputation etc.) and keep it after leaving the company. For real social media, this is probably fine, but I don't understand why we accept this model for Github and Gitlab (and Sourceware before that). Even from an employee perspective, it's not great because it makes it unclear who owns what. Especially with services like Github which have rules about how many accounts you can create for one person, and under what circumstances.
I have no idea how this is supposed to work in practice for Github and Gitlab, where people gain access to non-public areas of those websites, but they are still expected to use their own accounts which they keep after leaving their employer.
(The enterprise-managed Github accounts do not address this because they prevent public, upstream collaboration.)
This is why you store and match on the sso provider’s uuid, not on the email address. Emails are not a unique identifier and never have been. Someone can delete their email account and later someone else can sign up and claim the same email. Anyone matching on email addresses is doing it wrong. I’ve tried to argue this to management at companies I’ve worked at in the past, but most see my concern as paranoid.
I wonder why Google would make an SSO assertion along the lines of "yes, this user Bob has email address bob@example.com" in the situation where example.com is not under a Workspace account. Such assertions ought to be made only for Workspace (and Google's own domains such as gmail.com, googlemail.com, etc.) since outside of that it's obsolete proof as you say, i.e. it's merely a username of a Google account which happens to look like an email address, and nothing more.
You can create a google account with an existing email
https://support.google.com/accounts/answer/176347?hl=en&co=G...
I read the GP's question as "why" would Google allow that in the first place?
The reason is obvious: because a Google account gets you access to many a Google service without requiring you to open a Gmail account.
However, the question still stands: why does Google allow authentication with a non-Gmail/Workspace account? Yes, it would be confusing since not all Google Accounts would be made the same, but this entire class of security issues would disappear.
So it's the usual UX convenience vs security.
Alternative "fix" that's both convenient and secure is to have every company use Google Apps on their domain ;-)
Perhaps the following could be a solution to this issue?
Any OAuth provider should send a flag called "attest_identity_ownership" (false, true) as part of the uaht flow, which is set to true if the account is a workspace account or gmail (or the equivalent for other services), and false if the email is an outside email. Thus, the service handling the login could decide whether to trust the login or proceed otherwise, e.g. by telling the user to use a different OAuth service/internal mechanism where the identity is attested.
If anyone needs motivation of such unmanaged users, I actively use this feature. I have my own Google Workspace on my own domain. Years ago when I bought a Nest product I found that I couldn't use a Google Workspace account to access Nest. No problem, I create a consumer Google account under my Google Workspace domain. The email looks just like a Workspace account. And it doesn't need any additional Workspace licenses. (I no longer plan to buy any more Nest devices so I'll delete the account once my last Nest product stops working.)