6 ms·

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

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 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?

wutwutwat 2y ago
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.
hunter2_ 2y ago
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.
- yread 2y ago
  You can create a google account with an existing email https://support.google.com/accounts/answer/176347?hl=en&co=GENIE.Platform%3DDesktop https://support.google.com/accounts/answer/176347?hl=en&co=G...
  - necovek 2y ago
    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 ;-)
rkharsan64 2y ago
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.
- birdgoose 2y ago
  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.
  - zrobotics 2y ago
    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.
    - dantiberian 2y ago
      The issue here is that if company.com does not use Google Workspace and hasn't claimed company.com, then any employee can sign up for a "consumer" Google account using user@company.com. There are legitimate reasons for this, e.g. imagine an employee at a company that uses Office365 needing to set up an account for Google Adwords.
laz 2y ago
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.
- pfooti 2y ago
  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.
- deleted 2y ago
  [deleted]
kccqzy 2y ago
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.)
oliwary 2y ago
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.

wutwutwat 2y ago

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.

hunter2_ 2y ago

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.

yread 2y ago
You can create a google account with an existing email https://support.google.com/accounts/answer/176347?hl=en&co=GENIE.Platform%3DDesktop https://support.google.com/accounts/answer/176347?hl=en&co=G...
- necovek 2y ago
  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 ;-)

rkharsan64 2y ago

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.

birdgoose 2y ago
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.
- zrobotics 2y ago
  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.
  - dantiberian 2y ago
    The issue here is that if company.com does not use Google Workspace and hasn't claimed company.com, then any employee can sign up for a "consumer" Google account using user@company.com. There are legitimate reasons for this, e.g. imagine an employee at a company that uses Office365 needing to set up an account for Google Adwords.

laz 2y ago

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.

pfooti 2y ago
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.
deleted 2y ago
[deleted]

kccqzy 2y ago

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.)

oliwary 2y ago

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.