Comment by loginatnine

Comment by loginatnine 4 days ago

23 replies

View on Hacker News

I 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 error that lead to a reprovisioning of the user, etc.

I also fail to see how the proposed solution of having a 'A unique user ID that doesn’t change over time' is different from the `sub` claim. However, the new ID associated to the domain could make sense to enforce a strong 'Everyone from the @domain.com has access' statement.

[1] https://developers.google.com/identity/gsi/web/reference/js-...

Timshel 4 days ago

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

Reply View 12 replies
  • loginatnine 4 days ago

    I've been working with an app that uses Google to login for the past 10 years, and I've had problems with sub changing when these situations happened : - Domain change - Company being bought by another one and being integrated in their Google Workspace - Employee leaving and coming back

    To us, it's very very far from the quoted 0.04% which is to me very high. I had to deal with it 5-6 times in the past 10 years but of course that number will vary depending on the usage of your app and I'm not gonna venture and put a percentage on it.

    Reply View 6 replies
    • herczegzsolt 4 days ago

      In my opponion, all of those cases very well justify a manual check, or some sort of extended identification before the user is let in.

      It indicates a deeper cultural issue of "convenience/profit over security" if those are sufficient reasons to not check the sub parameter.

      Reply View 5 replies
      • chavesn 4 days ago

        > all of those cases very well justify a manual check, or some sort of extended identification before the user is let in.

        Just curious, what would that check look like that's not open to the same vuln?

        Reply View 4 replies
  • nixosbestos 4 days ago

    Exactly. How is there an entire alarmist article and 165 comments on this thread. This comment, and it's legitimacy/factualness, is the only thing worth discussing.

    `sub` _IS_ the immutable reliable identifier. If it's not, (1) I want to see actual proof, not an anonymous rando (sorry, but this thread re-inforces how little I trust context-less comments like that), and (2) I'd want to hear a convincing argument that ... `sub2` would actually be less mutable.

    Threads like this make me really question other peoples' general comprehension skills.

    Reply View 2 replies
    • ycombinatrix 4 days ago

      agreed. the real story is that people are ignoring `sub` out of convenience and creating a security hole.

      Reply View 0 replies
    • pl4nty 4 days ago

      every trufflehog post I've seen on hn has been alarmist clickbait. could've been an opportunity to discuss security tradeoffs of `sub` vs `email` and how to handle `sub` changes, but nope their take is "sub doesn't fix the problem we found"

      Reply View 0 replies
  • jorams 4 days ago

    0.04% is a few times higher than I'd expect it to be, but if it were actually that bad I'd expect some form of previous report about it to be findable on the internet. I did some searching but couldn't find anything. It would be a significant bug on Google's part, but stranger things have happened.

    What's astonishing to me is that apparently all these big service providers did notice, and then they decided to disregard the one identifier Google tells them to use? Fundamentally that's the security bug being reported here, it's just being reported to Google instead of those service providers.

    A stable alternative for the hd claim would of course be a good idea. It would provide a more complete way to deal with the inherent security issue of allowing domain-based signup without further authorization steps. But given the above I'm not convinced these service providers wouldn't start ignoring it after the first time somebody re-registers a domain with Google Workspace.

    Reply View 0 replies
  • confuseddeputy 4 days ago

    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.

    Reply View 0 replies
JohnMakin 4 days ago

I've implemented OAuth flow glue logic a bunch in my career and I agree that the logic doesn't seem to follow from what the documentation says. What's not clear to me though while reading this is, if I delete/lose a domain, and someone re-makes the domain and account with the same email address, does the sub value then change? The docs would seem to suggest yes, but then I am not clear what google actually ended up "fixing" in its bug bounty. Was that maybe the bug, and this is just not clearly explained in this post?

Reply View 1 reply
  • agf 4 days ago

    The reason this is an issue is that the sub value changes often enough that intergrations ignore it rather than bother users with having to re-OAuth.

    As far as what Google is doing in the bug bounty, that's a good question -- we don't know. The author is proposing two new values, for the domain and user, that wouldn't change in the cases that sub changes now, but would change in this case.

    Reply View 0 replies
jbmsf 4 days ago

There's a reason this happen though. Whether you like it or not and regardless what the standards say, people want a technology that matches with the identifiers they want to use (eg email) and not whatever opaque value happens to be in the sub claim.

I don't like blaming users for wanting something sensible.

Reply View 1 reply
  • tshaddox 3 days ago

    > I don't like blaming users for wanting something sensible.

    Are you saying that it's sensible to want email address ownership (and thus domain name ownership) to be permanently unchangeable?

    Reply View 0 replies
ticulatedspline 3 days ago

Yes this is not a "Google" problem so much as a "Your SaaS application is literally doing it wrong"

Having worked on a lot of SSO integrations I can say that everyone does it wrong.

I will also say that there is a super scary aspect to the sub claim (in general). It should be pairwise tied to the SP's integration, so if you only use google for auth, and for some reason you lost your google dev account and had to set up a new one you would drop credentials from 100% of your users.

for google I don't know if you can scope for the account ID (the opaque unique identifier) since that could expose privacy issues via cross integration tracking. But that's basically the fix. if you had the unique, immutable, opaque account identifier and matched on that this wouldn't work since buying a domain and setting up that email should result in a new account with google.

Reply View 0 replies
saguntum 4 days ago

Yeah, I'm not really clear on the vuln. It sounds like clients don't validate sub claims because they are unstable? Google's docs say they should.

When I first read the post, I thought that maybe Google was reusing sub claims when they shouldn't, but on a closer read, maybe it's the opposite problem - that the sub claim is changing when it should not change?

From the article -

“The sub claim changes in about 0.04% of logins from Log in with Google. For us, that's hundreds of users last week ... Because the sub claim is inconsistent, it cannot be used to uniquely identify users - leaving services reliant on the email and hd claims."

So maybe clients aren't using the sub claim because validating "email matches && sub matches" breaks real users who are not actually changing accounts? AKA, Google is changing Google Account IDs unpredictably? That would be a bug on Google's part IMO.

If those account IDs in the sub claim are changing, at the very least that's a bug in the doc you linked IMO.

I'd have to read the full OIDC spec [0] to see if the sub must remain constant for the same end user, and if clients are required to validate the sub claim before processing a login. If so, and it's changing without the end user's identity changing, that is a bug in Google's implementation and client implementations for anyone using Google as an IDP.

If it's allowed to change, though, and validating sub claim is not required in the spec, maybe clients are correct in not relying on it.

[0] https://openid.net/specs/openid-connect-core-1_0.html#rfc.se...

Edit: from reading the sign in with google overview, it's unclear if they claim to be OIDC compliant: https://developers.google.com/identity/gsi/web/guides/overvi...

it says it's "based on OAuth" rather than "implements OAuth+OIDC" so I guess not being fully spec compliant wouldn't necessarily be a "bug."

Reply View 2 replies
  • russelg 4 days ago

    I ran into this when implementing OIDC at work. One of my teammates wasn't able to login even though he just linked his google account. Turns out based on which browser session he was using, the same google login was giving a different sub. Super weird behaviour.

    Reply View 1 reply
    • j16sdiz 4 days ago

      very skeptical about this - I believe they are two accounts.

      It is possible to create two google account linked with same email address.

      I think I need more proof they are actually same account. For example, changing the profile pic in one session is reflected in another session.

      Reply View 0 replies
chavesn 4 days ago

Genuine question, what would that flow look like?

Reply View 0 replies
grumple 3 days ago

I mean, I see why it happens. It's because the client uses the email as the identifier for login - it is the only shared identifier between Google and Slack (or whatever service) to connect accounts. Sure, you could argue that maybe this is ok for the initial login, but the client app should record the sub...

Note that for regular logins without Oauth, you still have this vulnerability - if you gain control of me@company.com, you can login to any site that uses that for login. This is a fundamental weakness in the way we handle domain registration and email addresses.

Reply View 0 replies