13 ms·
I work in this space and have dealt with variants of this exact vulnerability 20+ times in the last 3-4 years across a wide range of login providers and SaaS co
by paxys 3y ago
I work in this space and have dealt with variants of this exact vulnerability 20+ times in the last 3-4 years across a wide range of login providers and SaaS companies. The blog post is correct, but IMO the core problem itself is too far gone to be fixable. Delegated auth across the internet is an absolute mess. I have personally spoken with plenty of Google and Microsoft engineers about this, so I can guarantee they are all already well aware of this class of problems, but changing the behavior now would just break too many existing services and decades-old corporate login implementations.
The "fix" at this point is simply – if you are using "Sign in with XYZ" for your site, do not trust whatever email address they send you. Never grant the user any special privileges based on the email domain, and always send a confirmation email from your own side before marking the address as verified in your database. All the major OAuth providers have updated their docs to make this explicit, as the post itself points out. In fact I'm surprised there even was a payout for this.
- tln 3y agoWhy couldn't Google prevent signups using domains of Google Apps customers? That doesn't seem like it would break anything.
- _cenw 3y agobecause the collisions can already exist when someone signs up for google workspace. and what are you going to do, delete those accounts? a lot of those would be personal accounts on educational domains...
- tln 3y agoThat's not a reason to not allow individual signups on @customer.domain AFTER customer.domain is a Google Workspace domain, which is the hole being discussed in the article. FWIW Adobe actually lets businesses take ownership of individual accounts with the same domain... see https://www.adobe.com/legal/terms.html https://www.adobe.com/legal/terms.html section 1.4
- meandmycode 3y agoGoogle has an ownership taking process, the user gets informed and during next login their address changes to a gtemp account and they are informed
- rnotaro 3y agoI used to have a google account with my personal domain then I registered to Google Workspace 4-5 years ago. Since then, I have this message when I log in : > Your account has been modified. > The address user@domain.com is no longer available because an organization has reserved rickynotaro.com. Why is this important now? > > Don't worry. Your data is safe. To use them, you must create an account with a different email address. Your password and security settings will remain unchanged. > Account details > > What type of account do you want to use? > > An account with Gmail and a new Gmail address > Select this option to add Gmail to this account. Unfortunately, we cannot move your data into an account with an existing Gmail address. > > Account using an email address belonging to you, not linked to Google. Ex.: myname@yahoo.com > Choose this option if you want Google products except Gmail. > Btn_Continue Btn_Do_it_later Not sure what to do? I've been pressing "Do it later" for years. I'm still using this account for youtube, maps and other services. I should probably use a secondary domain and use this address. Some service prevents me from changing my email address when signing with google and weird behavious happens when it tries to use my user%domain.com@gtempaccount.com Google documents it here: https://support.google.com/accounts/troubleshooter/1699308?hl=en&ctx=ch_AddressNoLongerAvailable&p=mail&sjid=10890393406904530700-NA#ts=1699315 https://support.google.com/accounts/troubleshooter/1699308?h...
- pcthrowaway 3y ago> Never grant the user any special privileges based on the email domain, and always send a confirmation email from your own side before marking the address as verified in your database Doesn't this fail if the user registered an account (on google) with the plus sign address, and then signed into your service with that google account before getting the boot? Unless you're sending a verification email for every sign-in...
- paxys 3y agoThe idea is that the company's Zoom admin should always specify the exact list of users who are allowed to be in their Zoom account. The email domain should have no bearing. So if you sign in as bob@mycorp.com, and that is a valid corporate account with the right permissions, you are let through. If you try bob+foo@mycorp.com, it should always fail. The pattern of "oh they have a mycorp.com email so they are probably legit" was broken from the start. This is thankfully less of an issue now since everyone is moving to SAML-based logins and SCIM provisioning.
- klodolph 3y agoWhat I’ve also seen is integrations with a different OIDC endpoint for company X. It’s still OIDC, but it’s not “sign in with Google”.
- SergeAx 3y agoThis will help, but at the same time will ruin the whole idea of seamless corp users registration in external service, and damage adoption and increase friction.
- krooj 3y agoI feel as though this is a consequence of organizations not really understanding how complex the space truly is. The way I've watched OAuth2 + OIDC get adopted in various companies was never from a security-first perspective; rather, it's always sold as a "feature": login with x, etc. Even when there are moves to make flows more secure - PKCE, for example - you end up playing a game of "whack-a-mole" with various platforms doing shitty things in terms of cookie sharing, redirect handling, and the like. The fundamentals of 3-legged OAuth2 are sound and there's tons of prior art (CAS comes to mind), but the OpenID Foundation should be tarred and feathered for the shitty way they market and sold OIDC.
- treve 3y agoOpenID Connect and all its extensions are so high in complexity and scope. The documents themselves are massive and written in a quite hard to understand form. I've implemented many protocols and RFCs so I feel I have some experience. Because OpenID Connect and OAuth2 are so closely related, I worry that some of this overengineering is making it's way back into new OAuth2 extensions. I'm worried both will eventually collapse under their own weight, creating a market for a new, simpler incumbent and setting us back another 10 years as all this has to get reinvented again. My outside impression is that the OIDC folks are highly productive with really strong domain knowledge and experience, but they're not strong communicators or shepherds with a strong enough vision. The sad thing is that this is the second thing with the OpenID name that's going down this path. The original OpenID concept was great but also collapsed due to their over-engineering.
- krooj 3y agoAgree - you only need to look at things like the hybrid flows to see where things fall apart: why would you issue an id_token that contains user information to a client which hasn't yet fully authenticated itself via a code-to-token exchange with passing it's client_id + secret? If you look at certain implementations, such as Auth0, you'll find that they actually POST that token back at the redirect_uri, since, a) it's at least registered against the client; b) it's not subject to capture as easily. The spec says NOTHING about protecting this info, though.
- SergeAx 3y agoBut in this particular case the attacker will actually receive a confirmation email, so what's the point?
- Racing0461 3y ago> always send a confirmation email from your own side before marking the address as verified in your database This would render the login with x feature useless from a user pov.