Hacker News Reader

Comment by Timshel | Hacker News Reader

It all depends on how true this statement is:

> “The sub claim changes in about 0.04% of logins from Log in with Google. For us, that's hundreds of users last week”.

I'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.

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.

> 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?

"Your account seems to have changed hands and is locked for your security.

The person paying for your subscription must contact us to verify your account is still legit."

Right, and how would you further verify “the person paying for your subscription”?

Payment info

For example a call to the registered owner or contact person of the organizaton (not the user).

Any out-of-band communication should work which checks for the legal entity, not just something that eventually relies on DNS.

Alternatively, you can always just not let them access the old user, and create a new one instead.

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.

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"

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

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.

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 on news.ycombinator.com