391–400 of 540 posts
[flagged]
good point, we think of these OAuth logins as so safe and yet they may be the exact opposite because it's more like logging in with your master password. I think these oauth providers like Microsoft and Google need to start mandating 2FA for every company login, it's just too dangerous otherwise.
When one OAuth token can compromise dev tools, CI pipeline, secrets and deployment simultaneously, something architectural has gone wrong. Vercel have had React2Shell (CVSS 10), the middleware bypass (CVSS 9.1), and now this, all within 12 months. At what point do we start asking questions about the concentration of trust in the web ecosystem? It's funny that at the engineering level we are continuously grilled in in…
Earlier quoted context omitted.
https://x.com/rauchg/status/2045995362499076169 > A Vercel employee got compromised via the breach of an AI platform customer called http://Context.ai that he was using. > Through a series of maneuvers that escalated from our colleague’s compromised Vercel Google Workspace account, the attacker got further access to Vercel environments. > We do have a capability however to designate environment variables as “non-sens…
> Still no email blast from Vercel alerting users, which is concerning. On the one hand, I get that it's a Sunday, and the CEO can't just write a mass email without approval from legal or other comms teams. But on the other hand... It's Sunday. Unless you're tuned-in to social media over the weekend, your main provider could be undergoing a meltdown while you are completely unaware. Many higher-up folks check company…
Wouldn't the CEO be... you know... the chief executive?
Earlier quoted context omitted.
I remember implementing OAuth2 for my platform months ago and I was using the username from the provider's platform as the username within my own platform... But this is a big problem because what if a different person creates an account with the same username on a different platform? They could authenticate themselves onto my platform using that other provider to hijack the first person's account! Thankfully I patch…
You should use the subject identifiers, not the usernames. You store a mapping of provider & subject to internal users yourself. But this has been a problem in the past where people would hijack the email and create a new Google account to sign in with Google with. Similarly, when someone deletes their account with a provider, someone else can re-register it and your hash will end up the same. The subject identifiers…
Now, I realize that this would require a large-scale conspiracy by the company/platform to execute but I don't want to trust one platform with access to accounts coming from a different platform. I don't want any possible edge cases. I wanted to fully isolate them. If one platform was compromised; that would be bad news for a subset of users, but not all users.
If the maker of an application wants to trust some obscure platform as their OAuth provider; they're welcome to. In fact, I allow people running their own KeyCloak instances as provider to do their own OAuth so it's actually a realistic scenario.
This is why I used the hash approach; I have full control over the username on my platform.
[EDIT] I forgot to mention I incorporate the issuer's sub in addition to their username to produce a username with a hash which I use as my username. The key point I wanted to get across here is don't trust one provider with accounts created via a different provider.
Earlier quoted context omitted.
Idk exactly how to articulate my thoughts here, perhaps someone can chime in and help. This feels like a natural consequence of the direction web development has been going for the last decade, where it's normalised to wire up many third party solutions together rather than building from more stable foundations. So many moving parts, so many potential points of failure, and as this incident has shown, you are only as…
This isn't a web development concept. It's the unix philosophy of "write programs that do one thing and do it well" and interconnect them, being taken to the extremes that were never intended. We need a different hosting model.
[flagged]
I'm not super savvy with OAuth, but shouldn't scopes prevent issues like this? https://oauth.net/2/scope/
Earlier quoted context omitted.
exactly this, write - not use some sh*t written by some dude from Akron OH 2 years ago”
That's why I wrote my own compiler and coreutils. Can't trust some shit written by GNU developers 30 years ago. And my own kernel. Can't trust some shit written by a Finnish dude 30 years ago. And my own UEFI firmware. Definitely can't trust some shit written by my hardware vendor ever.
Who is Apple?
When one OAuth token can compromise dev tools, CI pipeline, secrets and deployment simultaneously, something architectural has gone wrong. Vercel have had React2Shell (CVSS 10), the middleware bypass (CVSS 9.1), and now this, all within 12 months. At what point do we start asking questions about the concentration of trust in the web ecosystem? It's funny that at the engineering level we are continuously grilled in in…
Earlier quoted context omitted.
This isn't a web development concept. It's the unix philosophy of "write programs that do one thing and do it well" and interconnect them, being taken to the extremes that were never intended. We need a different hosting model.
Just throwing it out there - the Unix way to write software is often revered. But ideas about how to write software that came from the 1970s at Bell Labs might not be the best ideas for writing software for the modern web. Instead of "programs that do one thing and do it well", "write programs which are designed to be used together" and "write programs to handle text streams", I might go with a foundational philosoph…
GP said it's about taking the Unix philosophy to extremes, you say something different.
Anything taken to extremes is bad; the key word there is "extremes". There is nothing wrong with the Unix philosophy, as "do one thing and do it well" never meant "thousands of dependencies over which you have no control, pulled in without review or thought".
[flagged]