261–270 of 297 posts
It's not 100% clear to me, from reading TFA, what the actual vuln is. Suppose DankStartup folds and I, being a morally-dubious sort of fellow, purchase dankstartup.net which I then use to sign into DankStartup's O365, or DankStartup's ChatGPT as a DankStartup employee. Isn't that a failure on DankStartup's part, to not shut down their business accounts? And isn't it also a failure on e.g. Microsoft or OpenAI's parts,…
Earlier quoted context omitted.
And people are telling you that this is not possible with the Google public OAuth API. When Slack asks Google's public OAuth instance if user abc@example.com is valid, Google checks with the Google Workspace associated to example.com, and returns to Slack a response saying "yes, that user is valid, here is more information from example.com". This can be the same Workspace or another one, Google isn't really telling S…
> And people are telling you that this is not possible with the Google public OAuth API. Yes I understand, however it is possible to integrate Slack and Google SSO in such a way that it checks that the user belongs to the correct workspace, correct? Either via the SAML integration ( https://support.google.com/a/answer/6357481 ) or an internal Google OAuth integration? The purpose of the public Google OAuth API as opp…
Earlier quoted context omitted.
I don't see the problem here. We've already settled on DNS being the auhoritative authentication key for everything. If you bought the domain then you've bought the corporate identity. It's working as designed.
The flaw is the fact that companies go bankrupt and their data should die with them. In case of bankruptcy it might be impossible to hold on to your DNS and therefore risking old company data leaking.
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…
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.
It's crazy just how little effort it takes to get a "Google = bad" article to the top of HN. There is no vulnerability in Google OAuth. This is exactly how every OAuth server is supposed to work. If you take over a domain, you automatically own every email address in that domain, and thus whatever external account relies on that email for login. Heck the result would be the same even if that service didn't use Google…
Is this really just google=bad, though? I work at a startup and this seems like a legit security risk that I'm happy to learn about. It seems like the only mitigation would be to let your HR SAAS know when your company shutters and ask them to delete the records. Or just squat the domain yourself as an ex-employee.
I believe it is more the downstream providers fault for not terminating inactive accounts, and the failed startup's for not properly deleting their Google accounts.
Google can mitigate this as the author mentioned, but this is not their responsibility. They shouldn't be held liable because failed startups were stupid to not delete their data.
It's not 100% clear to me, from reading TFA, what the actual vuln is. Suppose DankStartup folds and I, being a morally-dubious sort of fellow, purchase dankstartup.net which I then use to sign into DankStartup's O365, or DankStartup's ChatGPT as a DankStartup employee. Isn't that a failure on DankStartup's part, to not shut down their business accounts? And isn't it also a failure on e.g. Microsoft or OpenAI's parts,…
ACL as in access control list.
Bell-LaPalda and multi-level access control systems both required a trusted controller and, And, AND a trusted arbiter of a state machine.
It is the state machine that magically got expanded into a couple more states, with the introduction of an imposter admin actor.
So yeah, the trusted arbiter and owner of that state machine (Google) did an oops.
This is something that Keberos (KRB5) was designed to protect against.
Earlier quoted context omitted.
I would argue the crypto bros are worse
crypto bros are annoying but at least they're doing their own thing. ICANN is actively screwing us.
Anything that gets put on the blockchain gets a secondary derivatives market that then impacts your own project. There is nothing you can do about this, they are created independently and can live on a different blockchain. They are so obsessed with financializing everything and turning it into a market where they can skim off everything out there
Okay, this made me curious if there was a technical solution to this that people could be providing using the existing tools available, and I think there is. RDAP and WHOIS will return the creation date of a domain. These fields are controlled by the registrar not the registrant. That creation/registration date gets reset when the domain is lapsed and picked up by somebody new. So, when doing any domain-name-based au…
Sadly, this isn't fool-proof. Domains can go up for auction or backorder on a registrar, and they won't update the registration date if the domain is purchased this way since the registrar can consider this a transfer. It's a signal, for sure, but it will miss cases. It will also miss transfers sometimes, depending on the registrar.
Registration date, last changed date, future expiry date. Even with domains that have well known dramatic histories. Which tells me the RDAP spec is not really enforced.
While I dislike "blockchain all the things" I can definitely see the argument for a blockchain-like global shared public ledger (albeit a not for-profit proof-of-work one) with full history for this sort of data.
Earlier quoted context omitted.
> And people are telling you that this is not possible with the Google public OAuth API. Yes I understand, however it is possible to integrate Slack and Google SSO in such a way that it checks that the user belongs to the correct workspace, correct? Either via the SAML integration ( https://support.google.com/a/answer/6357481 ) or an internal Google OAuth integration? The purpose of the public Google OAuth API as opp…
No, there's no way to check which workspace is in use, just that the domain matches. That's the problem.