[HN Gopher] Google OAuth is broken (sort of)
___________________________________________________________________
Google OAuth is broken (sort of)
Author : mooreds
Score : 299 points
Date : 2023-12-21 14:08 UTC (8 hours ago)
(HTM) web link (trufflesecurity.com)
(TXT) w3m dump (trufflesecurity.com)
| cedws wrote:
| Is it just me that feels $1337 is an insult? FAANG pays way too
| low bounties for this kind of stuff. This kind of info would be
| much more valuable on the black market.
| jjice wrote:
| Nope, I'm with you. Based on the quick blurb about what the
| vuln way, $1337 is an absolutely steal for Google. Paying for a
| team or outside pentesters to attempt to find this would be
| _way_ more expensive.
| nonethewiser wrote:
| It's essentially 0 as far as they're concerned.
| Cthulhu_ wrote:
| > Paying for a team or outside pentesters to attempt to find
| this would be _way_ more expensive.
|
| 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.
| twisteriffic wrote:
| Especially when Microsoft paid out about 75k for essentially
| the same issue.
| agwa wrote:
| Did Microsoft pay the entire $75k? The people who found
| that issue reported it to multiple stakeholders, and their
| blog post[1] merely says they were awarded $75k in total. I
| assume the bulk of the bounties were paid by the service
| providers who failed to heed the warning in Microsoft's
| documentation.
|
| 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.
|
| [1] https://www.descope.com/blog/post/noauth
| thrdbndndn wrote:
| From a practical perspective, they probably should "match" what
| black market values these exploits, and I surely wish they can
| give much higher bounties in general (and they for sure can
| afford!), but I don't think they ethnically need to (so it's
| not an insult in my view).
|
| 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".
| pcthrowaway wrote:
| > Turning these exploits/vulnerabilities to black market is
| not only immoral but also highly illegal
|
| 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.
| thrdbndndn wrote:
| I'm not a legal expert, but is it necessary for an act to
| pose a threat to "national" security for it to be
| considered illegal in places like the United States?
|
| 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.
| progmetaldev wrote:
| The United States has similar laws in place. There have
| even been cases where people were convicted for
| responsible disclosure, since they had to circumvent the
| system to determine that there was indeed an exploit.
| It's not as common as it used to be, but there are plenty
| of small financial firms that would still go after
| someone reporting an exploit.
| tptacek wrote:
| Zerodium isn't going to pay you $133.70 for this.
| aliceryhl wrote:
| If you pay too much in bounties, you risk having your own
| red-team employees leave so that they can report bugs
| externally and get paid much more via bounties.
| dtx1 wrote:
| I'd certainly try to sell the exploit to someone else instead.
| tokai wrote:
| Could at least have been $31337.
| sp332 wrote:
| Google hasn't fixed it, so it seems they really don't value
| this info.
| dpedu wrote:
| Per the article, Google fixed it, but only for google.com
| accounts.
| rahkiin wrote:
| Might this be because to be actually vulnerable a company needs
| to have the ticketing-like system in a sort-of unsafe setup?
| lightedman wrote:
| "Is it just me that feels $1337 is an insult?"
|
| Y0U 4R3N7 31173 3N0U6H 70 C47CH 7H3 R3F3R3NC3
| poizan42 wrote:
| They could have given them $313373 or at least $31337
| instead.
| pests wrote:
| A third of a million? You must be sky high.
| esafak wrote:
| So you're saying it's a joke on multiple levels.
| agwa wrote:
| To be clear, the information shows a rogue employee how to
| create accounts in third-party apps (Slack, Zoom, etc.) that
| won't be automatically deleted when the employee is terminated.
| I'd love to hear why you think this information would be "much
| more valuable" than $1337 on the black market as that is not
| obvious to me.
|
| 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".
| paxys wrote:
| In fact I'd argue that Google paying a bug bounty for
| something that is well-defined and documented behavior and
| will never be "fixed" actually undermines the program.
| dpedu wrote:
| > 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'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.
| agwa wrote:
| The rogue accounts would show up in the administrative
| settings in the third-party apps, and they would stick out
| like a sore thumb because they'd have weird email
| addresses. So they're not completely invisible, albeit not
| visible from one central place.
|
| > 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
| vultour wrote:
| Buy why should Google pay them at all? One of the first
| screenshots of their documentation says you shouldn't trust the
| email claim, so they're obviously aware of this issue. The
| problem is third parties using Google's OAuth incorrectly. If
| anything, Slack/Zoom/etc should be paying.
| toasted-subs wrote:
| Eh depends on if the person is financially stable. The tongue
| and cheek number may stand out stronger on a resume.
| LelouBil wrote:
| > Following this flow, you can create a Google account using a
| support ticket email address, potentially view the contents of
| the ticket to finish the account creation, and start using the
| support email address to Oauth into stuff.
|
| That could impact lots of small companies.
| CaptainOfCoit wrote:
| > Today I'm publicizing a Google OAuth vulnerability that allows
| employees at companies to retain indefinite access to
| applications like Slack and Zoom, after they're off-boarded and
| removed from their company's Google organization. The
| vulnerability is easy for a non-technical audience to understand
| and exploit.
|
| > October 5th- Google paid $1337 for the issue
|
| Is that a joke? Does Google really value security so low?
| bawolff wrote:
| If i read the post right, the behaviour in question was already
| mentioned in the docs before they reported this. I'm more
| surprised they got any money instead of a "its a feature not a
| bug" response.
| chuckadams wrote:
| Exactly. They paid for a detailed example they can point to
| of why one should follow the docs. Lot cheaper than a tech
| writer.
| dividuum wrote:
| Why is it even possible to create a new Google account with an
| email like 'user+suffix@domain' if 'user@domain' is already
| handled by google's mail servers and thus applies the plus-
| routing rules? Even in the non-exploity case that seems like a
| great way to create confusing mail setups.
| hypeatei wrote:
| I think this aliasing feature is too complex for its own good.
| Especially at Google's scale.
| paxys wrote:
| A domain can freely move between mail servers. Google has a
| specific handling for a+b@domain.com, other servers might not.
| At the end of the day they are two unique email addresses, and
| that's how they should be treated across the internet.
| asylteltine wrote:
| Because of how old and legacy googles authorization system is.
| A "Google account" is just a string.
| Racing0461 wrote:
| > user+suffix@domain
|
| 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.
| Too wrote:
| Another fun one is upper case vs lower case. I've been bitten
| by systems that are case sensitive, while the rest of the
| email world mostly is not.
| hudell wrote:
| I could swear I at least once received an email that was sent
| to myname.mydomain@gmail.com or something similar in my
| myname@mydomain email. It's been several years but I remember
| thinking that was fucked up and looking into the full email
| to see if there was any other explanation for me receiving
| it, which I did not find.
| paulddraper wrote:
| Google (and most email providers) also treat the user portion
| as case-insensitive.
| theK wrote:
| > * August 7th - The issue was triaged
|
| > * 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?
| j0hnyl wrote:
| Not sure about Google VRP, but I've gotten multiple payouts
| from Chrome over the years and I believe there's a schedule.
| The rewards panel meets every x weeks in order to award payouts
| on qualifying reports. Almost no bug bounty programs pay upon
| triage by the way, they pay after resolution.
| imroot wrote:
| I run a bug bounty program and I pay upon successful triage:
| while our engineering teams do have security SLA's, it's not
| fair to whomever reported the vulnerability to wait for our
| (sometimes broken) processes in order to be paid.
| rwmj wrote:
| It's pretty normal for large companies to take ages to pay up.
| The real problem here is this major bug only elicited a token
| $1337 payment.
| toasted-subs wrote:
| Yeah, definitely should have had a higher payout.
| theK wrote:
| > The real problem here is this major bug only elicited a
| token $1337 payment.
|
| Agreed.
| paxys wrote:
| 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 wrote:
| Why couldn't Google prevent signups using domains of Google
| Apps customers? That doesn't seem like it would break anything.
| asmor wrote:
| because 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 wrote:
| That'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 section 1.4
| pcthrowaway wrote:
| > 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 wrote:
| The 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 wrote:
| What 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 wrote:
| This 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.
| layer8 wrote:
| If a company has no directory of their employees,
| associated company email addresses, and employment
| status, they likely have much worse problems.
| SergeAx wrote:
| Most companies have these directories but in different
| forms, including Wiki pages. The idea of auto-enrollment
| is that it is based on a standard and widely adopted
| OAuth protocol.
| faeriechangling wrote:
| They sure have those directories in different forms out
| of sheer need but every time I've seen people have to
| consult wiki pages to get information that should be in a
| standardized directory it's a shitshow that is borderline
| impossible to automate.
| layer8 wrote:
| Employee records as wiki pages? That must be a joke,
| right?
| SergeAx wrote:
| Why not? If your company has lots of employees, like tens
| of them, you may create a nice template for those pages.
| IlliOnato wrote:
| Why not on a piece of paper then?..
| SergeAx wrote:
| It's hard to share and update.
| malfist wrote:
| > Unless you're sending a verification email for every sign-
| in...
|
| Isn't that your typical 2FA flow?
| andygeorge wrote:
| > Unless you're sending a verification email for every sign-
| in...
|
| 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.
| apitman wrote:
| > "Magic link" email + TOTP is pretty slick.
|
| Agreed. But unfortunately it's also highly phishable.
| johnmaguire wrote:
| Can you explain how you would phish a user with a magic
| link? Since the service is generating a one-time code,
| and sending it directly to the user's email inbox, I am
| not sure how an attacker would intercept the code.
| apitman wrote:
| The attack works by getting the user onto a page you
| control that looks like a slack page that says, "we need
| you to confirm your email". User enters their email and
| gets a legitimate email from slack. User enters the code
| on the original phishing page and the attacker gets a
| link that lets them log in as the user. I built this
| exact exploit for slack in a few hours. It was trivial.
|
| 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.
| archi42 wrote:
| The foolproof way is to not send codes as a 2FA (be it
| mail, SMS or whatever). There is always a risk that the
| user fails to verify where they're putting that code.
| Instead use something that verifies the domain without
| relying on the user, e.g. U2F or passkeys.
|
| 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...
| SgtBastard wrote:
| As with sibling comment, what threat vector do you see
| phishing risk with?
|
| 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?
| apitman wrote:
| See response to sibling
| krooj wrote:
| I 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 wrote:
| OpenID 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.
| SergeAx wrote:
| But in this particular case the attacker will actually receive
| a confirmation email, so what's the point?
| Racing0461 wrote:
| > 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.
| ses1984 wrote:
| You still get the benefit of not remembering an extra
| password.
| yardstick wrote:
| Would be be useless? Wouldn't the verification email happen
| once, then after which you gain all the SSO benefits?
| rowls66 wrote:
| Is this really a Google OAuth issue, or more failure my many
| service providers to properly verify the OAuth token assertions
| before allowing access? Seems to me the latter.
| kr0bat wrote:
| It sounds like the issue is that these service providers are
| obeying Google's aliasing rules, but also ignoring the fact
| that you shouldn't be using email as a primary identifier [1]?
| It's funny, if they had adhered to the spec more they'd be
| fine; but if they adheredess and treated alias' as distinct
| emails, these platforms would at least be more secure.
|
| [1] https://developers.google.com/identity/openid-
| connect/openid...
| mikea1 wrote:
| I believe OAuth is working as expected. It provides valid
| authentication/identity for email addresses because
| "user@domain" and "user+wildcard@domain" are still validated as
| email addresses "owned" by the user.
|
| 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.
| rwmj wrote:
| My main takeaway from this is that web authentication is still a
| horrible mess.
| c0pium wrote:
| ...because people don't read the docs and instead just assume
| that it works how they think it should.
| asylteltine wrote:
| If so many people are making the same mistakes, it's your
| fault, not the users.
| c0pium wrote:
| If people don't read, it's their fault. Reading the docs is
| not a big ask.
| asylteltine wrote:
| Typical engineer spotted.
| pests wrote:
| How dare we read documents before we put technology into
| use.
|
| Like asking a bridge engineer to know the spec of his
| bolts.
| asylteltine wrote:
| And if every purchaser of said bolts implemented them
| incorrectly, is it more likely that your specs, docs, or
| bolt design are faulty? Or do you just think no it's
| everyone else who is stupid?
| scottyah wrote:
| I don't think that's engineer so much as lazy bureaucrat
| in power. It's the mentality Douglas Adams made fun of
| with the "Your planet is being destroyed, you had plenty
| of time to read the posted notice".
| apitman wrote:
| Documentation (including code comments) are vital and
| important, but it's far better to bake the proper
| constraints into the code/specs so that it's hard to make
| mistakes. Then the docs are less necessary, shorter, and
| easier to understand. I think this is what GP is getting
| at.
| wnevets wrote:
| Sounds like a classic footgun to me.
| physicsguy wrote:
| Half of it I think is because people take "basic auth"
| offered by web framework, and then try to retrofit
| OAuth/OIDC/SSO on top of it.
| toasted-subs wrote:
| This is why login is a horrid mess. Because if it's too easy
| then people who don't know what they are doing set up
| websites.
| Too wrote:
| Have you seen the oauth docs? I can't imagine anyone having
| read and understood them fully, unless you dedicate your life
| to it.
| Dalewyn wrote:
| When some people ask why most of us sane and practical folks
| still use and demand simple password authentication, it's
| because passwords _fucking work_.
| JohnFen wrote:
| So much this. OAuth and their ilk are, in my opinion, not
| trustable and suffer from real usability issues.
| lesuorac wrote:
| I'm still firmly in the mutual TLS camp. Nothing is easier
| then never having to type in a password and good luck
| cracking TLS.
| apitman wrote:
| > I remember being surprised to learn that Microsoft would send
| Email claims that were not created or validated by Microsoft, and
| that the email claim in general was not considered reliable.
|
| > 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
| throwawaaarrgh wrote:
| > I believe email addresses should be treated as identities.
|
| Because nobody ever shares an email address, and email is super
| secure
|
| We can wait forever or we can begin building the solution
| apitman wrote:
| Sharing email identities is a reasonable way to give group
| access to a resource.
|
| And solutions are being built. The mission of LastLogin is to
| accelerate this.
| caseysoftware wrote:
| > _I believe email addresses should be treated as identities._
|
| 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._
| bastawhiz wrote:
| > 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.
|
| 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.
| mtaba wrote:
| Plenty of other reasons to "lose" a phone number.
| Especially temporarily. Accounts deemed inactive. Locked
| devices, in some cases.
|
| 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.
| caseysoftware wrote:
| I'm not advocating _for_ phone number, simply saying that
| "assuming/forcing email is insufficient"
|
| Giving people the option between phone, email, or whatever
| is a better approach so they can plan accordingly.
| Jnr wrote:
| Sadly more and more countries require mobile service
| providers to check identity of the user before providing a
| phone number. Not everyone wants to be easily identifiable
| IRL. Meanwhile, unique e-mail addresses are available by
| anyone without proof of identity.
|
| And the goal more often is to identify a unique user, not
| have a user that can be traced back to real life.
| k8svet wrote:
| I think it would be really great if you could compare/contrast
| LastLogin with Dex. Especially given they're both Go. Just
| curious if you evaluated dex, etc.
|
| 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. :/
| apitman wrote:
| See the table here: https://github.com/lastlogin-
| io/obligator#comparison-is-the-...
| k8svet wrote:
| Hats off, what a README.
| clintonb wrote:
| Related: More service providers need to stop using email as the
| primary identifier (as Google's docs recommend). When I changed
| my username on Google Apps, I spent a lot of time dealing with
| issues at Slack, Datadog, GoLinks, and others.
| mattgreenrocks wrote:
| What should providers be using?
|
| I've always presumed email was the most stable global
| identifier for a user, but that assumption appears to be wrong.
| sirius87 wrote:
| Curious to hear answers to this too. People forget usernames
| and that alone would lead to drop off. People are also
| reluctant to give out phone nos. which is anyway a terrible
| identifier and has the same issues as email.
| rajasimon wrote:
| Why can't the phone number be unique? I have a unique phone
| number and trust them as my email unless I transfer myself
| out of my country.
| JohnFen wrote:
| Just like with email addresses, there are a nontrivial
| number of people who share the same phone number.
| SoftTalker wrote:
| Phone numbers are also recycled, probably much more often
| than email addresses.
| crote wrote:
| Just use an integer or GUID or something as primary key. It
| is still totally fine to use an email address as username, of
| course - just keep a separate email-to-user mapping and don't
| use the email _itself_ as primary key.
|
| 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.
| andygeorge wrote:
| > Just use an integer or GUID or something as primary key
|
| 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.
| saurik wrote:
| Those providers already don't use email addresses as
| _their_ primary key: their login APIs all allow you to
| get access to an underlying ID of the user (I say "an"
| as, in the case of Facebook at least, they no longer give
| you the global one but map you to an application-specific
| one, to prevent 3rd party apps doing correlation).
| lykahb wrote:
| The subject identifier, "sub".
| merb wrote:
| Microsoft basically has no useful sub (sub is only useful
| when it comes to app credentials for Microsoft). It has
| oid, but if you want to support n-providers with just a
| login field and not a sign in with n button, than you have
| a problem. Or should the user know its entry lid and insert
| it into the username field? Most of the time you use an
| email and what Microsoft does in c# and their docs mean
| that you connect that with the oid. And also that's why
| it's stupid that Microsoft and google do not treat the
| email/preferred_username identifier that well. Because
| everybody changes the oidc spec
| frenchyatwork wrote:
| Is Microsoft's sub claim unstable?
|
| 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.
| merb wrote:
| No the sub is not unstable, it's just the sub is unique
| per client_id.
|
| 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.
| apitman wrote:
| I disagree with GP. I think email is generally a solid
| identifier, and would be curious to know why they needed to
| change theirs.
| kagakuninja wrote:
| Because comcast subscribers lose their email address when
| switching email providers, and the address becomes
| available to other subscribers.
|
| 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.
| rngname22 wrote:
| also known in industry as Account Takover
| apitman wrote:
| This is solvable by using a more stable email provider,
| ideally with your own domain. And yes I know domains need
| to be much easier for the average person to use (and
| avoid accidentally losing). That's one reason I run a
| domain registrar, to try and make this more accessible.
|
| 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.
| JohnFen wrote:
| > This is solvable by using a more stable email provider,
| ideally with your own domain.
|
| 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?
| deathanatos wrote:
| If you're logging in with OIDC (as is the case w/ the OP),
| the combination of the issuer and the `sub` claim identify
| the user (the "subject"). The relying party (the system
| wanting to authenticate the user) just treats sub as an
| opaque string (unique within that issuer). The `email` claim
| is just the "End-User's preferred e-mail address." (And ...
| "The RP MUST NOT rely upon this value being unique" ... the
| end user's email might change ... for whatever reason the
| end-user, or their IDP, might prefer. Also, any other IDP
| might claim that email as the preferred email, potentially
| truthfully, too.)
|
| 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 consider1 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.)
|
| (1The 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.)
| yardstick wrote:
| This is how we do it- sub+issuer associated with an account
| in our system. The user is issued a username for our
| system, they enter that then they are presented with the
| login options (eg password, IDP providers, etc). This also
| forces the customer organisation to specify exactly who
| they want to have access (which in a org with 10k+
| employees of which only a few dozen need to login to us,
| that's a good thing).
|
| Plus this approach allows multiple accounts each associated
| with the same IDP account. Useful if the user needs
| multiple accounts for whatever reason.
| jbmsf wrote:
| I get it, but this is also, frankly, terrible. I should not
| be required to store your identifiers in my system in case
| order to login users.
|
| 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.
| kagakuninja wrote:
| I have a comcast email named after an old movie monster.
| Turns out that a former comcast customer once had the same
| account, and registered it with google (and others). Not only
| can I not use that address with google services, creating
| google calendar events using my email will sent the
| notification to the other guy (as a result, I created another
| email address for job interviews).
|
| 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.
| philote wrote:
| If you own the Comcast email address, how is he registering
| anything with it? Wouldn't he need access to the email to
| verify his accounts?
| bobthecowboy wrote:
| Because a shocking number of services don't actually
| require you to verify you control the email address. I'm
| talking about mainstream services like Spotify.
|
| 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.
| kagakuninja wrote:
| He used to own the account, now I own it. I've tried
| resetting the google account password and the like, there
| seems to be nothing I can do.
| JohnFen wrote:
| > I've always presumed email was the most stable global
| identifier for a user, but that assumption appears to be
| wrong.
|
| 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.
| smeyer wrote:
| I changed my last name when I got married, and at the time I
| had a work email address that looked like
| oldlastname@company.com on the company's Google Workspace.
| Given that oldlastname was no longer my name, I changed my
| email address to newlastnmae@company.com.
|
| 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.
| jbmsf wrote:
| I can't agree. This guidance just pushes responsibility down
| onto application developers and I would expect most of them to
| either do nothing or implement guidance inconsistently.
|
| 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.
| merb wrote:
| Well the best solution is basically to allow the creation of the
| account but keep it deactivated so that a human needs to check
| it. That at least works for things like gitlab or other things
| were an Organisation signs up. The problem of the hd claim is
| actually not one since you need to validate your domain and if
| your a saas provider that is b2b only that's ok. Microsoft is
| even worst tough, where you need a different claim than email,
| depending on what you are doing. (UPN)
| superkuh wrote:
| A microcosm. There is no such thing as OAuth2. OAuth2 is just a
| way for megacorps to implement their own arbitrary/proprietary
| auth systems. It is a toolkit for making auth systems, not an
| auth system. So we end up in a world where oauth2 was supposed to
| be a standard, but instead every megacorp has their own
| incompatible implementation. And sure, people will dev for the
| megacorp use cases... but that just means the "standard" is now
| whatever google does/etc.
|
| 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.
| kevindamm wrote:
| I wouldn't really call this a bug, more like an unfortunate
| side effect of combining these particular components: domain
| names that can change ownership, BYO email (as backup email &
| email provenance), the liberal allowance of plus-aliases (which
| I'm sure someone somewhere is claiming a business need or they
| would have killed it long ago), and service implementers not
| reading the documentation (or largely copying solutions from a
| video or example with cut corners for brevity/simplicity,
| likely to facilitate its easy consumption).
|
| 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.
| paulddraper wrote:
| Um...okay?
|
| Is cross-provider compatibility related to this article about
| the security of _Google OAuth2_?
| physicsguy wrote:
| The OIDC _spec_ tells you that you must not to use e-mail as a
| unique identifier. You must use the 'iss' and 'sub' fields as
| username in your application.
|
| 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.
| k8svet wrote:
| Sometimes reading articles like these are a good well to
| alleviate any accumulating imposter syndrome. "Oh, I'm
| interfacing with a third party system for something that
| represents an abstract actor. it better have a stable, non-
| stringy reliable identifier". And yes, the spec is very clear
| about this, beyond just basic considerations of building a
| remotely robust system.
| SergeAx wrote:
| Not that I am being vain (though I actually am), but how's that
| my post of the same link 4 days ago got just one upvote? :)
|
| https://news.ycombinator.com/item?id=38670644
| JohnFen wrote:
| Whether or not a link gets any attention here depends on a lot
| of things aside from the link itself. For instance, if it
| happens to hit the front page at the same time as something
| else that is drawing everyone's attention then it may simply go
| unnoticed.
|
| 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.
| sam0x17 wrote:
| > October 5th- Google paid $1337 for the issue
|
| love the tongue-and-cheek "leet" amount of 1337
| wizofaus wrote:
| Anyone else unable to access what I assume are supposed to links
| for the centred bits of text throughout that article? I had a
| hard time understanding parts of it...
| ok123456 wrote:
| This is a feature, not a bug. Anyway, what is to stop someone who
| owns a domain from doing this with actual forwards to do this
| sort of ban evasion?
| FergusArgyll wrote:
| I may or may have not used a version of this to sign up for
| multiple free trials - for multiple products.
|
| sign up johndoe@gmail.com then next time johndoe+1@gmail.com then
| +2 ad infinitum
| intrasight wrote:
| I use OAuth2 all the time. And I don't understand the conflation
| of email and OAuth2 being discussed in that article. With
| Google's OAuth2, I can get the user's email - but so what? I have
| no need for it and I never use it.
|
| "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.
| VoodooJuJu wrote:
| I'm struggling to understand how to reproduce this.
|
| 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?
| uxp8u61q wrote:
| Just try it, google will merrily redirect all emails to
| a+b@org.com to a@org.com. To answer your questions:
|
| > 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.
| egamirorrim wrote:
| What am I missing here? Outside of the support system/zendesk and
| unattended old domain methods identified I can't make a new
| Google account for whatever@mydomain.com without being asked to
| verify it - so what's the real likelihood of abuse?
| JeremyNT wrote:
| The idea is that you do this in advance, at a time when you
| have legitimate access, then you later lose that access.
|
| 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.
| AtNightWeCode wrote:
| Using emails like this is usually found during pen tests. Not
| Googles fault I would say even though I think OAuth is overly
| complicated. This is along the line of sending secrets in the
| token. Tokens are signed, not encrypted.
| theteapot wrote:
| I found the article confusing. Not sure how "noAuth" Azure vuln
| relates or how it relates to Google oAuth specifically. What's
| the actual vulnerability?
|
| Is it that you can create a validated email address alias that
| outlives your actual corporate Gmail address which you can use to
| login to certain services (like Slack) after your email account
| has been deleted??
___________________________________________________________________
(page generated 2023-12-21 23:01 UTC)