Live data from Hacker News

Why Single Sign on Sucks

goteleport.com

31–40 of 124 posts

Re: Why Single Sign on Sucks

#31
post #4

My experience is completely opposite of the author's. I sign on once a day when I access a service that uses my firm's SSO solution. I'm then automatically signed in to all other services as I use them. It's quite seamless. I have no complaints about the SSO setup in my firm.

So your company doesn't have certain functions where someone has said "this is really critical so we'll force a sign-in even if the SSO token is already there" because that happens to me 10 times a day at my work.

Yes, this does happen. Especially for HR related matters. But that's definitely more of an exception than the rule. For most services that I use on a day-to-day basis, the experience is seamless.

Re: Why Single Sign on Sucks

#32
This is the problem Kerberos solved. It solved it well.

You log on to your workstation, do whatever auth dance, and then that ticket gets used by SSH, your web browser and everything else to seamlessly log you into other services.

When it works, it works really well, but absolutely no one implements support for it.

Re: Why Single Sign on Sucks

#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.

Re: Why Single Sign on Sucks

#34
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…

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

Because employers see how some employees act as they depart, even though they don't act similarly around their coworkers. Employers also see trusted employees smile and leave for competitors even after signing that they would not do that. Employers are right to suspect departing employees, because some steal information or otherwise cause issues before they leave.

> So it troubles me a bit how quickly the C Suite prioritizes having a giant switch to lock people out.

I've seen dozens of systems that had to be accounted for when an employee left. Almost all of those systems required separate action to remove the departing employee, plus follow-up checks that sometimes had to be from humans.

It only makes sense to have your employee separation procedure get automated, and during automation it makes sense to communicate with one system instead of communicating with 30 systems that each respond in different ways - some of which require human intervention.

Re: Why Single Sign on Sucks

#35
post #30
post #20

Earlier quoted context omitted.

As an enterprise cloud software business, I will not allow my systems to handle user-chosen long-lived credentials like the passwords you describe. Sorry, it's too much of liability. Got any other ideas? (sincerely curious)

At some point, your user also has right to make their own policies. Imagine your banker requiring you to take a drug test before they let you do any action, would that be fine by you? If you were talking about your employees, of course, it's less of an issues, but you are still open to them misusing other solutions: in the end, invasive security policies in a business where people can also use service accounts is a r…

I'm not following you but very curious!

I have no issues getting my enterprise customers to configure SSO, so there's no practical reason for me to support password login.

In the consumer space, which is not my area of expertise, it seems that combinations of "passwordless" and OAuth are working for successful companies.

Where is the last bastion of places where a user can justifiably demand a password login option?

What do you mean by invasive security practices?

Re: Why Single Sign on Sucks

#36
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…

My pet peeve is having to change my password every 3 months. I can practically guarantee all the employees use some form of incrementing number.

Re: Why Single Sign on Sucks

#37

My grief is having a plethora of phone authenticor apps and now the loss of my phone (even being out of power or just switched off) is catastrophic.

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

Re: Why Single Sign on Sucks

#39

I thought my signin woes were finally solved after moving everything over to 1Password. It works great and auto-fills usernames/passwords and TOTPs with a shortcut. But Github recently rolled out a default 2FA that uses their app on my phone instead of the 2FA code. Luckily they support switching back to TOTPs for now. But now that passwordless is the new sign-in meme, i can look forward to having to migrate everythi…

I thought my signin woes were finally solved after moving everything over to 1Password. It works great and auto-fills usernames/passwords and TOTPs with a shortcut. Doesn't that dilute the value of MFA and essentially make it SFA? If someone compromises your 1Password app or password, then they get both factors of authentication. what if an employee leaves their laptop unattended I think that's what automatic screen…

> Doesn't that dilute the value of MFA and essentially make it SFA? If someone compromises your 1Password app or password, then they get both factors of authentication.

Yep, that's the point. I have been using the internet for 20 years now and have somehow managed to not get hacked by using unique passwords, not clicking on porn pop ups or falling for phishing attacks and updating my OS occasionally. I take a risk every time I drive a car or drink alcohol or even walk around my neighborhood. We can't bubble wrap the entire world and make risk disappear. So i like SFA because its convenient, even if it may be marginally more risky. I literally cannot imagine a solution with 0 risk, and its foolish to keep moving to new security "best-practices" trying to pretend one exists.

Re: Why Single Sign on Sucks

#40
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 token/session cookie should be good enough right?
Post reply on HN