Comment by api | Hacker News Reader

Comment by api | Hacker News Reader

Parent Full thread

Totally meta to this discussion: I am disturbed by the SSO/IAM trend because it gives root on the entire universe to a small collection of companies.

We are looking at a future where a security breach or misbehavior by one of a handful of companies could mass-compromise millions of businesses and critical infrastructure and possibly hundreds of millions to billions of devices. Even worse this permission is clandestine. It could be exercised against individual targets with no obvious audit trail, since auditing tends to also be delegated to the IAM provider (and nobody looks at local logs in most cases).

I guess we've been handing vendors a lot of power for a while with OS vendors that have "push" software update capability, but this is adding not only even more carte blanche permission to a small number of companies but extending it across systems running different OSes and even open source platforms like Linux and BSD.

Software update capability is also fairly coarse grained. Apple or Microsoft could push a compromised or malicious update, but it would be harder for them to specifically target a single user reliably and without being noticed. (Wait... why did I get a macOS update and none of my friends did?) SSO/IAM providers could easily do this. Imagine a subpoena that targets your SSO/IAM provider that gives the government (and maybe not even your government!) silent unlimited remote access to everything you have.

I can also imagine "cancellation" scenarios where a company doesn't like what you say so they dump your account and lock you out of all your infrastructure, requiring you to manually go around and "root" all your stuff. (If you think this would only ever be deployed against Nazis, study history a bit. Political winds shift.)

It's just a monstrous amount of power to give out, and I feel like people aren't thinking this through or maybe are not even aware of the power they are delegating.

I feel like people should at least understand what they are doing when they choose to delegate all their authentication to Google.

> I feel like people should at least understand what they are doing when they choose to delegate all their authentication to Google.

I think this is my biggest concern, it's really scary to have Google Auth as literally the only barrier between no access and complete production access. I understand that a lot of the time Google accounts hold the literal keys to the kingdom anyway (customer data, internal company data, maybe source trees), but SSH was one of the last frontiers remaining.

it may also be a relic of my old age, but the idea that a browser cookie could be all you need for production root has terrified me in sso environments of past.

maybe i have an antiquated view of browser security but it seemed... unnerving.

There is a reason why many companies (especially those with few developers, artists etc, so most people run Windows), go with Azure AD as their SSO solution. Then they are only depending on Microsoft not being compromised. But they are already relying on other parts of Microsoft not being compromised, so it feels like less of a risk to those companies.

This is correct.

One answer is to have many, many SSO/IDP systems -- and for anyone technical enough to set up a homelab to be able to be their own IDP.

A lot of people don't let you bring your own IDP. They offer a few choices: Google, Microsoft, Okta, etc.

I can foresee this eventually being a revenue stream for a lot of companies where they charge payola to be listed as an IAM provider, sort of like the browser CA inclusion or browser default search engine list rackets.

I'd love to know of well supported, secure IDP software to use for this. I'm afraid of OpenLDAP due to its long history of security issues. What are the open source alternatives that are both minimal in configuration and solid enough to be exposed to the internet if necessary?

Keycloak is Java based, but its simple to setup and configure and requires no OpenLDAP.

It supports both SAML and OpenID Connect/OAuth2. With an LDAP backend you can also use that LDAP backend for other services that don't support those two protocols for SSO, but it is not required.

Authelia is the fast minimal solution.

Keycloak offers a much more "roll your own" design.

https://www.authelia.com/

>Wait... why did I get a macOS update and none of my friends did?

That's an easy one to circumvent if you don't need to install the malware Right Now: just wait until the next update cycle and slipstream your targeted malware in with it.

I've seen this conversation before, but I've never been clear on what exactly the consequences of the SSO are. I imagined, it might be that the provider gets an IP address when you connect or something. You're saying they potentially get _access as you_? Am I understanding that correctly?

Anything authenticated with SSO can be accessed by the SSO provider since they're able to approve any authorization, which means they can just log into all your stuff.

So e.g. if you use "log in with Google" on a web site, Google now has access to your account too (if they behaved badly or were compromised).

Spreading SSO auth everywhere gives the SSO provider login access to absolutely everything you have.

wait so if i authenticate tailscale using google and enable tailscale ssh's google can just log into any of my tailscale ssh servers?

I have not tried Tailscale SSH or looked at it deeply, but as a general rule the answer is yes if the system is using delegated SSO alone to authenticate. (What I don't know is whether TS SSH supports any secondary methods like a password or SSH auth forwarding.)

You are delegating authentication, so your delegated authenticator can authenticate anything they want.

I feel like a large number of people adopting SSO/IAM systems don't fully understand this. If they do understand and are making a cost/benefit based choice to do this that's one thing, but... I think people should understand.

I've never used or examined Tailscale either, but I assumed that:

- Tailnet traffic needs to be associated with an approved device key

- Tailnet device addition needs to be signed by the offline key of another approved device

If a compromised control plane and/or SSO provider can add and approve devices on their own then the security architecture of Tailscale would be fundamentally broken. I wouldn't even call it end-to-end encrypted.

Reply on news.ycombinator.com