Live data from Hacker News

Why Single Sign on Sucks

goteleport.com

91–100 of 124 posts

Re: Why Single Sign on Sucks

#91
post #54

The author's complaint is really against authentication in general rather than SSO. Different sites and services have always and will always use their own authn/authz methods, simply because it isn't a generic problem that can be abstracted away. You can outsource parts of it (show the user a username/password form, validate credentials, verify email, check 2FA) which is what all these SSO providers aim to do. Also t…

Same - I sign in once and all the other apps is a click away.

From the author’s gifs, it looks like their SSO is setup incorrectly AND being incorrectly used. The 1st gif is really bad, the subsequent ones are more typical SSO setups.

Also, this blog article is an ad for Teleport. Given their flawed premise, … yeah.

Re: Why Single Sign on Sucks

#92
post #18

I feel like this article misses the point that SSO is intended to benefit organisations, not users. The selling point is that if an IT department can point a new service at Active Directory or something, it's going to be much less of a headache than managing n sets of user credentials.

I can think of two times in my life where I even considered the possibility that one of my peers would do something malicious on their way out the door, but management worries about this all the time. On the one hand, Precautionary Principle. The costs of being wrong - and having to explain it to the Board - are just unimaginable. So sure, if you want IT to have a way to push a button and block someone out of the ent…

Ignoring the "actual security" angle for a minute.

When you have thousands of accounts and dozens to hundreds of services, manual management just stops being practical.

Most large orgs are subject to one form of compliance or another, and it's inevitable that at some point you have to prove to an auditor that you have onboarding / offboarding processes for everything as that's in their checklist.

This is difficult to prove "at scale" and removing tons of per-service UAR processes is the main value. Each service is an opportunity to screw up - forget to document the process, forget to execute the process, (my favourite) forget to record that you executed the process, or execute the process wrong.

The alternative to automation in a big company is that accounts get left dormant for years.

Re: Why Single Sign on Sucks

#93
post #33

I feel like this article misses the point that SSO is intended to benefit organisations, not users. The selling point is that if an IT department can point a new service at Active Directory or something, it's going to be much less of a headache than managing n sets of user credentials.

No, SSO also helps me. Having only one password to change is really nice. It’s the SSO process that annoys me. Between all the redirects and duplicate information, signin takes 4 times longer than user/password auth.

My company's single-sign-on got upgraded with mandatory 2FA a couple years back, and somehow requires it every time. It's really more of a non-stop-sign-on, I probably do it 10 times on any given day (including waiting for the SMS, etc, I wonder how much this one poorly-configured service costs them).

Re: Why Single Sign on Sucks

#94
post #73
post #50

Earlier quoted context omitted.

> Employers who ask their employees to sign immoral and usually illegal non-compete clauses deserve whatever they get, honestly. Employers should expect their employees to go work for competitors when they leave. That's my point as to why employers want to immediately stop access to employees who leave for competitors. > An ecology management company fires and ecologist and they clutch their pearls when that ecologis…

If that was the goal, wouldn't you do that in advance anyway before any suggestion you were bailing?

Sure, but it doesn't always happen like that.

You're in sales at a company in a highly competitive space and are exited. You're not the kind of person to premeditate taking anything with you, perhaps you left on good terms. You join another company and someone there asks you for the book of business or sales leads you were working on that the previous company. Oh look, your login to the CRM system is still working, and you can get a glimpse of information that you shouldn't have access to as a non-FTE. It seems benign, so you copy down a few phone numbers and email addresses. This isn't an academic example.

This wouldn't even be a possibility if the account was locked down immediately. It's obviously much more difficult to control access to information while you are employed (this is a subplot of Snowcrash, afterall), but immediate lockout isn't meant to mitigate that risk. It's meant to mitigate risks from an account being active that shouldn't be.

Re: Why Single Sign on Sucks

#95
post #57

Earlier quoted context omitted.

This. I recently got a new iPhone, most auth tokens didn’t xfer across (presumably they’re in the Secure Enclave). I’m root in some services including azure and aws tenancies. I have no idea what would happen if I lose my phone, as opposed to replacing it with the old phone next to me for a month for this exact use case

The solutions I've heard of usually involve a screenshot of the seed QR code stored in a safe somewhere. Not optimal, but at least gives you a backup in case of disaster.

This doesn’t work for push based auth, unsure if they support Totp fallback though

Re: Why Single Sign on Sucks

#96
post #18

I feel like this article misses the point that SSO is intended to benefit organisations, not users. The selling point is that if an IT department can point a new service at Active Directory or something, it's going to be much less of a headache than managing n sets of user credentials.

I can think of two times in my life where I even considered the possibility that one of my peers would do something malicious on their way out the door, but management worries about this all the time. On the one hand, Precautionary Principle. The costs of being wrong - and having to explain it to the Board - are just unimaginable. So sure, if you want IT to have a way to push a button and block someone out of the ent…

ignoring all of this, the fact that you can use SSO and then people will have access to most services without having to login to most of these services (loads of services have "anyone in this G Suite org can get into your account") is a godsend.

No more chasing around for each service figuring out who is the admin for what.

Re: Why Single Sign on Sucks

#97
post #12

Article does a decent job of calling out some usability issues with SSO, but doesn't investigate the impact of these usability issues on security. Security and usability are often in tension - if we're going to improve usability, our proposed changes also need to improve security, or they're dead on arrival. (which is incidentally how we got to this place of horrendous usability) Indeed, there are some material secur…

> Security and usability are often in tension - if we're going to improve usability, our proposed changes also need to improve security, or they're dead on arrival.

I'd actually say it's the other way around. One of my favorite quote related to that is "security at the expense of usability is at the expense of security". If you force users to rotate passwords, they'll use some form of continuous passwords and/or stick them with notes to their monitors. If you'd need to sign in all the time, users will be less careful and choose easier passwords. If it takes 20 seconds to authenticate at the front door, it will only take a few days until someone puts a brick there to keep it open. To improve security, you'll absolutely need to consider the UX; improving the UX while not caring about security, OTOH, works quite well in my experience (until it blows up in your face, which might be years away or even a moral hazard).

Re: Why Single Sign on Sucks

#98

Maybe someone can answer this, why are client certificates not more popular instead of something like VPN for work? I suppose even with client cert, you would still need to login, though if your computers login is already managed through AD/ldap or something and you enforce timeout logout policies you could argue that if you are logged into your machine that is good enough. Even if not, then a client cert plus a SSO…

I think it's because A) developers don't know about it, B) users don't understand it and C) the UI for it is quite terrible. Implementing it requires some uncommon TLS configuration and a little cert work. Using it prompts uncommon native popups, slowing people down. Failure leads to weird redirects for which you can't really fall back to a login prompt because the auth happens on TLS level and a token in HTTP can't…

> Failure leads to weird redirects for which you can't really fall back to a login prompt because the auth happens on TLS level and a token in HTTP can't replace that.

That's not true. nginx, for example, let's you return a custom response, which can easily be a 302 to the login page.

But I agree with all other points. On a sidenote, there's also the great option of using a CA for your client certificates while still using a normal CA for your https certificate - you don't have the worry of installing a root certificate on all clients and still have a nice, valid https connection in the browser. Unfortunately, hardly any tutorials pointed this out and used their own CA for everything instead.

Re: Why Single Sign on Sucks

#99
SSO using TLS client certificates would be ideal if the support for it in browsers wasn't so terrible. The UI is bad, support isn't universal, features (like ) keep getting dropped etc.

Re: Why Single Sign on Sucks

#100
post #60

I feel like this article misses the point that SSO is intended to benefit organisations, not users. The selling point is that if an IT department can point a new service at Active Directory or something, it's going to be much less of a headache than managing n sets of user credentials.

I also don't think that the client certificate solution that is trumpeted at the end (for which I don't blame them, content marketing has to content market) is a great option. From the post: "The UX and tech for PKI Infrastructure isn’t great, and the client UX sucks." Guess what, it has for years and years. Deployment is hard. Creating certs at scale for normal users has been available for a long long time, but no o…

Having persisted with user authentication X509 for years, I can in fact tell you the UX got _worse_ over time. We wound up sometimes making key pairs and certificates for end users and emailing them because browser enrollment is so shonky.
Post reply on HN