Google OAuth is broken (sort of)
trufflesecurity.com
trufflesecurity.com
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.
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.
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...
This is thankfully less of an issue now since everyone is moving to SAML-based logins and SCIM provisioning.
Hate to break it to you but SAML is same shit different coat of paint, the xml encryption/signature/encoding stuff it pulls makes it just as much a tarpit for bugs and misconfiguration.
SCIM seems pretty decent though to explicitly state who is and isn't on the Guestlist.
On my second startup we payrolled via Google Spreadsheet. By the way, it is also an okay storage for employee data.
It's above all, a security nightmare, since the wiki pages are perpetually out of date and incomplete, and it makes the process of thing like provisioning and deprovisioning access so labor intensive.
Yes, absolutely do this! This is what Slack does, and what we do at my current employer (defined.net). "Magic link" email + TOTP is pretty slick.
Agreed. But unfortunately it's also highly phishable.
I've never seen a foolproof way to mitigate this. Best you can do is big warnings in the email telling the user never to enter the code anywhere but slack.com. You can also do fancy stuff like comparing IP addresses to make sure they're from the same region but the attacker can also do fancy stuff like detect where your IP is from and use a VPN to get an IP in the same area.
In that case the user needs to be fooled to sent the physical device or passkey-app-backup to the attacker. This is much more suspicious and needs a much worse fool than someone entering a code after they already entered their user+password.
If you know that the user uses the same browser to open links sent via mail as they use for their login: For the 2FA step, set a cookie with some unique value on your login domain and sent the user a mail with a link. Opening the link only finishes the login and starts a valid session if that unique cookie is present. This makes it harder for an attacker, since they need to inject that cookie into the victims browser, which means they need to find an XSS-style exploit. Of course you then want to reduce the attack surface by putting the login function on a subdomain of its own.
And obviously this fails if the user is about to login e.g. on their personal computer and then tries to verify the session on their company phone. This can be good or bad, depending on the scenario.
TBF, I wish some companies would use even that basic code-by-whatever 2FA. I've seen cases which have like 5 different domains, all with various logins that customers and employees use. Want to phish them? Just register another domain that looks similar enough to the others and sent some mails. But then there are still services limiting the password length to something like 16, so I think we will still have plenty of work...
A magic link is a link a user clicks in their browser, that lands them on the appropriate service, where the one-time code is part of the URL. The service consumes the token and provides the user with a (first factor) authentication token.
In other words, the email doesn't display a code which they could go paste into the attacker's page. Though they may still need to perform a 2FA flow following the magic link flow (and this portion is still phishable!)
Your critique is definitely valid for most forms of 2FA (email, SMS, and TOTP.)
However, the method you're describing has fallen out of favor, in large part because mobile email apps often use a built-in browser that doesn't share cookies with the system browser. This creates several confusing UX problems. You also can't use a logged in device to log in a new device, unless you implement something like QR login which is also phishable.
Slack for example used to work the way you describe but now uses emailed codes for 1FA login.
A race condition where the phishing email lands first, user clicks link to g00gle.com, gets a convincing message that they also need to present username and password?
Magic link is a process where you enter your email address and the service sends you an email that contains a clickable hyperlink that contains a cryptographically strong, short-lived nonce in the URI that is used as a proof-of-possession factor (the email account) to authenticate users.
Isn't that your typical 2FA flow?
This would render the login with x feature useless from a user pov.
FWIW Adobe actually lets businesses take ownership of individual accounts with the same domain... see https://www.adobe.com/legal/terms.html section 1.4
> 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?h...
I've always presumed email was the most stable global identifier for a user, but that assumption appears to be wrong.
The docs, however, seem to be discussing the notion of the relying party's "user" object. For that … use a UUID, an auto-incrementing int, some artificial key, totally up to you. Link that user object with the (iss, sub) tuple above. But you should consider¹ whether user can adjust their authentication method with whatever you're building: e.g., if I change OIDC providers … can I adjust in your RP what IDP my account is connected to? (Same as I might need to update an email, or a password in a more classic login system.)
(¹The answer is also not always "yes", either; I work with a system where the IDP is pretty much fixed, because it's a party we trust. All signins have to come from that specific IDP, because again, the trust relationship. But, on the open web where I'm just building Kittenstagram, you don't care whether the user is signing in with Hooli's IDP, Joja's, etc.)
Plus this approach allows multiple accounts each associated with the same IDP account. Useful if the user needs multiple accounts for whatever reason.
I've always felt that email+email_verified would make much more sense.
I don't actually care about the email address being a unique person, just that they have access to it.
No one wants to build an application that has to invent its own id scheme or manage this complexity. That fact that the specs don't provide a solution here -- something like informing you when an email address is no longer valid (again, I get it, this is hard/impossible) -- means that the spec will always be in conflict with actual usage.
Treat the email address like a name field: it's probably not going to change, but don't make it impossible to do so when someone wants to.
We're not talking random apps and services, we're talking about the big providers that are commonly used for SSO, where "just change ur primary key" is wildly impractical at best, and more likely impossible at their scale. That ship, as it were, has already sailed.
This worked fine in Google services and some of the many work applications using Google for auth, but some of them were using the email address as a global identifier in a way that broke down when I changed my name. The services that migrated successfully were using a more stable identifier that persisted despite the address change.
Every year I get several notifications that this guy has done something with his x-box, or registered a new device for something or other. It is absolutely nuts, and companies like Google refuse to let people like myself claim our own email addresses.
I'm in a similar situation, except in my case, the person providing the wrong email address never controlled it - it's firstnamelastname@gmail.com, which I signed up for when gmail was still invite only.
If I go to sign up for a service that someone else has signed up for with my email, I just do a password reset, and take control of the account. Either by transferring it to another email address that doesn't exist and then creating a new account, or if that doesn't work I just nuke the data.
It might be the most stable, but that doesn't mean you can assume that it's at all stable.
Also, email addresses can't be assumed to uniquely identify a single person -- lots of people share email accounts with others.
I think you might have misunderstood the point. Miscellaneous claims like email/preferred_username shouldn't be used to identify 3rd party logins. Apart from not necessarily being unique, they're also vulnerable to change. Changing your email shouldn't make you lose access to all your accounts. The point of the sub claim is that it's it's unique and stable.
yeah I know that. We basically do both. You create the account with the email/upn but we also save the oid and than we use the oid for matching. If the email changes we update it. If you started your account without the provider and than somebody configured domain+tenant id we first match via upn and after the first login it will use oid. User still uses upn to start the flow but the matching uses oid. But we are only dealing with b2b tough. And we have our own login site that of course needs a upn as well, thus the upn of Microsoft is the same as ours. If you change the upn on the Microsoft side you need to change the login upn on our side aswell. Another solution would‘ve been to have a unique logon site, in this case it would be possible to directly go to the IdP, but it does not matter that much with login_hint.
I might verify the number, and then stuff happens in the real world while I haven’t logged into your service, and someone new registers with my number.
The number is assigned to my account, but the new account can prove they own the number. If you’ve made the number unique, then you need special handling here.
This happened to me, and I cannot use my comcast email with google services, and some others. I need a separate email address for job hunting, because google calendar will assume the provided email address is linked to google services, and the notifications will go to the other guy.
It is really fucking annoying.
Once someone has their own domain, it also opens up things such as hosting your own IdP (or paying a small monthly fee to have someone else host it for you) and sidestepping email entirely.
Sure, but requiring ordinary people to do this is essentially a nonstarter. The whole point of SSO is to minimize user friction. Requiring a user to also set up a special email account with another service is a dramatic increase in friction, and I expect that a large percentage of users simply won't do it. Why would they?
The right thing here is to offer APIs that fit the needs of the applications that will use them with as little extra responsibility as possible.
In this case, I'd have hoped that Google would set email_verified to false so that applications (or downstream IDPs) would know that they had to do extra verification.
I am not saying that my solution works today. I am saying that is a completely natural thing to want and the fact that it doesn't work or that we're even having this discussion is failure of the people who designed and implemented these specs.
No deeper understanding required.
It's even worse than that. At least the +XYZ is specified in the email rfc. Google has decided even further that periods in the name also go to the cononical email. ie hi.my.name@google.com is equal to himyname@google.com and routes all emails to the second.
> This was counter-intuitive to me, because I had thought the entire purpose of OIDC was to establish reliable identity via a 3rd party like Microsoft.
That might have been the original intent, but I find it very useful that OIDC can be more flexible. For example, I run a free login provider[0], and it works by validating an identity with a 4th party identity provider (IdP) either with upstream OIDC or direct email, and creating a privacy screen between the app and that IdP (ie so Google can't track every app you're logging into). The fact that you can bring your own email to Google means you can get the security and UX of Google OIDC with the privacy of email + password, with the huge caveat that now you have to trust LastLogin instead of Google. But we're working on protocols to reduce that dependence.
> Google’s documentation in fact warned against using Email as an identifier
I completely disagree with Google on this. Email is the only truly federated identity that people actually use. Until we have something better widely deployed (and there are some promising alternatives in the works), I believe email addresses should be treated as identities.
[0]: https://lastlogin.io
No, for two reasons:
Outside of the western world, phones are more common than computers and easier UIs in general so a phone number is more likely to be their identity.
In addition, that means you're completely handing off your identity to your email provider. Considering many - looking at you google - are faceless organizations that can and will shut down your access without notice or appeal, you could lose everything.
Background: I launched Okta's OAuth and OIDC products, put together LinkedIn's courses on the same, and doing it again at Pangea Cyber.
When I worked at Stripe, we found that far more people lost access to phone numbers than email addresses. And the reason is simple: if you can't pay your phone bill, you lose your phone number.
While going through support tickets to tabulate which auth issues we should focus on, I came across one person who had a Stripe balance that they needed to feed their kid. But they couldn't log in because they couldn't pay their phone bill and had lost their number. The very fine support folks got the situation resolved with other identity checks, but it was a huge wakeup call.
You simply _cannot_ use an identifier that requires ongoing payment for identity purposes. You and I are probably privileged enough to never have to worry about this, but everyone who falls below the lower middle class is entirely vulnerable to losing _everything_ this way.
> you're completely handing off your identity to your email provider. Considering many - looking at you google - are faceless organizations that can and will shut down your access without notice or appeal, you could lose everything.
Versus handing off your phone number to organizations that routinely get socially engineered to transfer phone numbers. This is such a common attack that my mom knows about it. Ironically, the facelessness of most email providers also protects you from having your identity yoinked out from under you by one of their staff: I don't personally know a single person whose had their email turned off as a result of social engineering.
What makes the situation intolerable is the proliferation of Google-inspired "customer service" designed to prevent any prospect of useful contact with paying customers. Kafka-esq nightmares are currently an everyday hazard.
Giving people the option between phone, email, or whatever is a better approach so they can plan accordingly.
Ideally I would like to see people hosting their own IdP servers from their laptops at home over something like ngrok but e2ee, but we have a ways to go for that.
Aside: given your background at Okta and ngrok, we have a lot of overlapping work. I'm curious of your thoughts on my LastLogin.io project?
And the goal more often is to identify a unique user, not have a user that can be traced back to real life.
Because nobody ever shares an email address, and email is super secure
We can wait forever or we can begin building the solution
And solutions are being built. The mission of LastLogin is to accelerate this.
I built LastLogin.io to provide the SSO UX without sacrificing privacy and to eventually move towards better protocols for user-controlled identity
Also toyed with... Portier (nee Mozilla Persona). But ultimately dealing with this email normalization seemed like a losing/hard battle. And I mostly accepted that I'll likely die before a good solution is pioneered here and have refocus attention elsewhere. :/
[1] https://developers.google.com/identity/openid-connect/openid...
The issue is with the Google org website: admins cannot revoke credentials for accounts/emails they cannot see.
> Because these non-Gmail Google accounts aren’t actually a member of the Google organization, they won’t show up in any administrator settings, or user Google lists.
That could impact lots of small companies.
Like asking a bridge engineer to know the spec of his bolts.
I’m sorry that you wrote buggy code because you didn’t read. But it’s the height of arrogance to assume that because you did, everyone else surely must have as well.
Why? Well, for a start, it's obvious that user e-mail addresses can be re-used. If you've got a contractor working for Business A and Business B, both who create a user account in their authentication service for them, then as a SaaS platform, you can't match their e-mail address to a single B2B customer.
Secondly, there's the really obvious thing that e-mail addresses change. Businesses get bought, change name, go through mergers, etc. etc., and people's names change too (marriage, divorce, because they feel like it).
I found implementing SSO to be really challenging for a start-up. Getting it correct is hard, and you need to have a good understanding of the general concepts and OIDC and OAuth2 before trying to put it into use. Auth0 have a good book. If you don't understand this, then you'll probably end up doing something like implementing password grant auth everywhere and leave your application insecure.
And they all have their own little bugs like this. We should go back to oauth1. It was a real standard. Not a toolkit for making standards.
If I were designing a circuit with a few PCB components and needed to introduce resistors and transistors as appropriate for the voltage and current needs of the device .. would you expect me to read the data sheet or just guess it from a simpler example and run with it? In a lot of cases the circuit would still work, or it would after a few bench tests and a bit of probing. But maybe it wouldn't be as efficient and a component would short out leading to low MTF and sad customers. Worst case scenario maybe combusting batteries and real harm. Now ask yourself, is it really the PCB modules' manufacturers fault that the device fails prematurely? Or is the device manufacturer the one responsible for reading the data sheet?
I don't typically hold all software to such rigorous expectations but when it deals with authentication and authorization I would expect service owners to be thorough.
TFA even says that the issue doesn't exist if the docs are followed. Alphabet did at least acknowledge there's a weakness there by granting the bounty, maybe they'll provide some controls for company administrators to allowlist/rejectlist plus-aliases or nonexistent roles, or maybe restrict the migration of Apps-affiliated emails to non-org claims? (My guess is they're measuring the impact of this, or prioritizing the measurement of impact, where priority is low because it is a problem with clients that assume email claims are more authoritative and permanent than they actually are).
I suppose the definition of "bug" depends a lot on the definition of "expected" and who's expecting, but I would assert it is not a deviation from intended behavior, at least, and not unexpected to those who grokked the docs.
Is cross-provider compatibility related to this article about the security of Google OAuth2?
So say you have a egamirorrim@mydomain.com google account legitimately. You can use an alias like egamirorrim+woopsie@mydomain.com to create a new google account with a verified email address, resulting in "log in with google" google sending an email claim egamirorrim+woopsie@mydomain.com.
Then, later, mydomain.com fires you. You can no longer log in with the real egamirorrim@mydomain.com associated account, as it was disabled by an administrator. However you can still log into the new google account, egamirorrim+woopsie@mydomain.com , since it's not associated with your organization.
The thing is, afaict this then only becomes a problem if the provider is doing authz based exclusively off of the email claim. I've used OIDC in the past and you are not supposed to grant access to resources based on parsing text in email addresses claim!
I can understand why the blog post author found this counterintuitive, but as they note the docs even warn against doing this.
The blog post goes on to make this statement:
> Most of the service providers I tested did not use HD, they used the email claim.
... OK, well what are they "using" it for? Does this trick actually work on any real world services? If so, I would like for them to be named and shamed.
Even if you (erroneously) assume this value is unique and immutable, that alone doesn't necessarily grant access to anything in and of itself.
love the tongue-and-cheek "leet" amount of 1337
sign up johndoe@gmail.com then next time johndoe+1@gmail.com then +2 ad infinitum
I have a Google Workspace organization: org.com
I create a new user: sneed@org.com
Where/when/how is the sneed+alias@org.com created? How is the user sneed@org.com doing this if they don't have administrative access to organization management?
> Where/when/how is the sneed+alias@org.com created?
Where: in gmail's alias list
When: at account creation
How: gmail/gw redirect everything of the form abc+xyz@domain to abc@domain
> How is the user sneed@org.com doing this if they don't have administrative access to organization management?
The user isn't doing anything, it's a "feature" of google mail.
"Because these non-Gmail Google accounts aren’t actually a member of the Google organization, they won’t show up in any administrator settings, or user Google lists."
I don't understand that statement either. They do show up. Now of course the org could choose to not do anything to manage the access of those users - which is common enough. I made a tool used by some of my larger clients to a) get reports of users and their permissions (available via Google's APIs) and b) batch delete those user permissions.
Also, although this isn't the case here, if it's just a link without a description or some sort of commentary explaining why the link is of interest, it may not get the traction you'd expect.
> * October 5th - Google paid $1337 for the issue
Is it just me or does it seem a bit odd that payout after triage took almost two full months? Initially I was positively surprised that they came up with a triage verdict within 2-3 days but what's the deal with the payout coming so late?
Agreed.
Also, if anyone should be paying bounties, it's the third-party apps, since they're the ones which are vulnerable. I'm impressed Google is paying a bounty just for pointing out a footgun. I would probably not have bothered reporting this to Google if I had found it; $1337 would be more of a pleasant surprise to me than an "insult".
That's why. This bug allows an attacker to retain access to various accounts attached to an already-compromised company or employee of the company. Not only that, but the retention is completely invisible to the account administrators.
Needing the same level of access that an employee has in order to utilize it doesn't make it less valuable. There are plenty of valuable bugs that can only be utilized from specific positions. Consider how many hacks have happened because an employee's devices or accounts were compromised, rather than some server system that no one individual owns. The recent Okta hack happened that way.
> Needing the same level of access that an employee has in order to utilize it doesn't make it less valuable.
The only way that would be true is if compromising an employee account has no cost, which is obviously not the case. Thus, attackers would prefer to purchase a vulnerability that doesn't require also compromising an employee account.
I trust tptacek is correct that Zerodium wouldn't even pay $133.70 for this: https://news.ycombinator.com/item?id=38722395
But doesn't Google have teams of internal pentesters already? You could hire dozens of external companies and they might not find it.
This system is a "no cure, no pay" approach. I do think they should have paid the reporter a lot more though.
Also, the Microsoft issue was far worse as it could be exploited by anyone; the Google issue requires a rogue employee or a misconfigured email ticketing system.
Turning these exploits/vulnerabilities to black market is not only immoral but also highly illegal, so the "value" is inflated due to these "risk" factors. You can't really expect the same from the affected company themselves.
It's like saying if you found a lost item and you ask a large sum from the owner when you return it, because "I can get much more if I choose to just sell it on the street".
I assumed 'black market' here means irresponsible disclosure, which there are many sites operating legally (Zerodium being a prime example)
Who are the customers? Theoretically nation-state actors, but do we really know? Either way, you're selling the vulnerability to a private party. To my knowledge, selling knowledge of an exploit to almost anyone is legal (unless it could be classified treason or a threat to national security or something).
As is publishing the security research after responsibly disclosing (as the blog author did here), though we've had to fight pretty hard to get to the point where warning people of threats to their digital safety (often because companies are too lazy to protect their users) is generally understood to be legal.
In my country, we have a law known as "The Crime of Destroying Computer Information Systems." This law makes it a criminal offense to intentionally harm computer systems in a way that could compromise them (which is somewhat vague in its definition, I'd admit). This includes leaking private information from these systems, and it applies even if the affected systems belong to private entities. And if you sell exploits to a third party and are later caught, you will be considered an accomplice and there are precedents for this.
Y0U 4R3N7 31173 3N0U6H 70 C47CH 7H3 R3F3R3NC3
> October 5th- Google paid $1337 for the issue
Is that a joke? Does Google really value security so low?