Don't let domains you use lapse. Never get rid of a phone number.
A lot of these new TLDs have variable registration fees. They're going to price a lot of people out of renewals.
Google’s OAuth login doesn’t protect against purchasing a failed startup domain
181–190 of 297 posts
Re: Google’s OAuth login doesn’t protect against purchasing a failed startup domain
#182Earlier quoted context omitted.
Well, think about it this way: 1. I create DankStartup and my company uses Google workspaces and Google auth for a bunch of stuff, like payroll. 2. DankStartup goes under and we close our Google accounts/let our domain lapse. 3. Someone else buys DankStartup.com, sets up a Google workspace, and attempts Google auth to log into stuff, and it works. The problem is that the original DankStartup has a Google account that…
>>>The problem is that the original DankStartup has a Google account that they create in #1, and Google goes around telling other sites (via Auth) "this is user X from company Y". Google is telling other sites that it's bob@DankStartup.com - isn't that true? Isn't this on DankStartup to close down operations cleanly?
It's a different bob@DankStartup.com, and in fact a completely different DankStartup.com. Google shouldn't conflate the two.
There are exactly 0 situations where the current behavior is useful. There is no reason whatsoever to have the exact same auth info for two Google accounts that happen to have the same domain.
Re: Google’s OAuth login doesn’t protect against purchasing a failed startup domain
#183Earlier quoted context omitted.
Well, think about it this way: 1. I create DankStartup and my company uses Google workspaces and Google auth for a bunch of stuff, like payroll. 2. DankStartup goes under and we close our Google accounts/let our domain lapse. 3. Someone else buys DankStartup.com, sets up a Google workspace, and attempts Google auth to log into stuff, and it works. The problem is that the original DankStartup has a Google account that…
> They are (or were) refusing to provide any indication to those other companies that these are not, in fact, the same people That is not quite true, the sub field will be different.
This is not necessarily useful. The sub field only indicates that this is a different user, which maybe protects the private info of the old user. However, a big part of OIDC integration is to automatically allow any valid user registered with the IdP to automatically have access to the corporate account, and to any company-wide resources, which can still include very sensitive information.
Re: Google’s OAuth login doesn’t protect against purchasing a failed startup domain
#184So the "sub" claim does work but the "staff engineer at a major tech company" doesn't want to fix it because it happens too often?
Re: Google’s OAuth login doesn’t protect against purchasing a failed startup domain
#185I really don't understand here, the proper way to use Google's OpenID implementation to authenticate someone is to use the `sub` claim. Don't use the email, don't verify it yourself, use the `sub` claim. It's a known fact and is properly documented[1]. If the `sub` changes, it's because it's not necessarily the same person so have a flow ready for that. It could be an employee left and came back, a domain change, an…
It all depends on how true this statement is: > “The sub claim changes in about 0.04% of logins from Log in with Google. For us, that's hundreds of users last week”.
I am pretty confident that the statement is false.
The `sub` claim value is equivalent to the user ID that's exposed in the Directory API, it's derived from the underlying user account's unique user ID, and it won't change unless the user account is recreated.
Re: Google’s OAuth login doesn’t protect against purchasing a failed startup domain
#186Earlier quoted context omitted.
"Your account seems to have changed hands and is locked for your security. The person paying for your subscription must contact us to verify your account is still legit."
Right, and how would you further verify “the person paying for your subscription”?
Payment info
Re: Google’s OAuth login doesn’t protect against purchasing a failed startup domain
#187It's crazy just how little effort it takes to get a "Google = bad" article to the top of HN. There is no vulnerability in Google OAuth. This is exactly how every OAuth server is supposed to work. If you take over a domain, you automatically own every email address in that domain, and thus whatever external account relies on that email for login. Heck the result would be the same even if that service didn't use Google…
Is this really just google=bad, though? I work at a startup and this seems like a legit security risk that I'm happy to learn about. It seems like the only mitigation would be to let your HR SAAS know when your company shutters and ask them to delete the records. Or just squat the domain yourself as an ex-employee.
Yes it is, otherwise the title would be "don't use your email address to log in to any application" and it wouldn't be ragebait enough. The whole issue has nothing to do with OAuth and nothing to do with Google.
Re: Google’s OAuth login doesn’t protect against purchasing a failed startup domain
#188It's not 100% clear to me, from reading TFA, what the actual vuln is. Suppose DankStartup folds and I, being a morally-dubious sort of fellow, purchase dankstartup.net which I then use to sign into DankStartup's O365, or DankStartup's ChatGPT as a DankStartup employee. Isn't that a failure on DankStartup's part, to not shut down their business accounts? And isn't it also a failure on e.g. Microsoft or OpenAI's parts,…
I agree, I don't think this is a problem with Google's Oauth implementation, it's a problem with the service providers who authenticate users via the mere existence of an email address ending in @company.com without checking if the email address actually belongs to an active employee. If, when you logged into Slack via Google Oauth with the email address user@company.com, Slack checked with company.com whether user@c…
First of all, the whole point of SSO is that the only and final source on who are the valid active users is the IdP, in this case Google's public OAuth instance. If the IdP says that the current request is coming from the real user1@example.com, you give them access. And Google's public OAuth instance will confirm this even if the current Google Workspace associated with example.com is a different one than a few months ago (though the "sub" field of the attestation will be different than before, which the service provider is supposed to check).
Second of all, even if it was recognized that this is a different user1@example.com, they'd still have access to all sorts of company internal resources, that may still contain sensitive data, especially for small companies which inherently trust all employees.
Re: Google’s OAuth login doesn’t protect against purchasing a failed startup domain
#189Earlier quoted context omitted.
I register a Google Workspace and add CorpDomain.com to it. I then use that to OAuth to other companies (e.g. Slack, payroll companies, etc.). Then my company goes under or closes up and the domain lapses. Someone else comes along, registers a completely different Google Workspace but attaches that same domain to it. The e-mail address is the same, but it's obviously a new Google Workspace with new people, new paymen…
I'm not entirely clear on what you expect in this case? You're registering with those 3rd parties using a property (the email address under corpdomain.com) that is now owned by the new party. This feels a lot like complaining that you hired a lawn service and told them to mow at your address, and then didn't update the address or cancel service after you moved. You've sold the domain. Assets associated with the domai…
> Legally speaking, it's not even clear you're right - the new person might well be the person actually entitled and expressly supposed to be accessing that service as that account (if the domain was sold as part of an acquisition or sale).
No, this is absolutely not the case. If you were selling the identity, you would transfer access to the Google Workspace account. There is no reason whatsoever that a new Google Workspace account should have access to the same services as a completely different Google Workspace account just because they happen to use the same DNS domain.
Re: Google’s OAuth login doesn’t protect against purchasing a failed startup domain
#190Earlier quoted context omitted.
>Then, the impostors in step #3 create a different google account with the same domain, and Google says "yeah, these are definitely the same guys as before", even though Google is fully capable of discerning that that is not the case; these are different people with a different workspace account, different names, different payment information, and so on, but Google is saying that if you're holding the domain you are…
Traditionally, SAML / OIDC trust is established using public/private keypairs. Each IdP/SP pair gets a unique combination. In this case, a domain changing hands would not allow the new owner to gain access to the old owner's accounts. In the case of Google OAuth, it's possible to forego this in order to allow any Google user from any Google workspace to login to your application. See the distinction between "public a…
To clarify, any multi-tenant app that has a Google login button that "just works" without you having to set up your own OAuth client creds is using the "public" app option. Effectively the OAuth client side doesn't care whether you use a public Gmail account or enterprise Workspaces account to login.
However, on the Workspace Admin side you can set policies as to whether the org accounts can login to arbitrary public apps by default, or set up an app allowlist, etc. It's definitely a best practice not to let your users login to arbitrary apps, even if it's only for the profile data and not other API scopes.
If you do login to a public app with an org account, how that app decides to group/authorize users from (what it perceived as) the same org/domain could be a sensitive procedure with opportunity for exploit, and it seems like maybe Google should offer a more reliable unique org id claim.
If you are making your own internal app then client is going to be internal only by default. Note this is managed in a GCP project. If you're using Workspace and GCP then you may want to use GCP services with built-in Google auth like Cloud Functions, App Engine, Identity Aware Proxy, etc.