Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Single Sign on Sucks

goteleport.com

Post reply on HN
Print view View original

51–60 of 124 posts

Re: Why Single Sign on Sucks

#51

Post by phh »

IncRnd wrote: post #34
hinkley wrote: post #18

Earlier quoted context omitted.

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 th…

> Because employers see how some employees act as they depart, even though they don't act similarly around their coworkers

It's fun, because in my experience, departing employees are always playing ball, while employer starts doing stupid things.

In France, we have 3 months (!) of resignation notice (and it usually really lasts 2). I've always seen departing colleagues still working the whole notice. However managers start asking stupid things "please prepare demo for this prospect, it should take you one month and a half, so 2 weeks to spare!", "hey we need this feature, you're the only one who can do it, please code it before you leave", but rarely "write documentation for everything you did".

> Employers also see trusted employees smile and leave for competitors even after signing that they would not do that.

What? Such clauses actually exist and are actually used?

In France, such a clause requires (ex)employer to pay at least 50% of salary during the period where the (ex)employee isn't allowed to work for competitors (I can't see how this can be a fair agreement without that compensation), but companies pretty much never enact those clauses, because well, they don't care about employees going to the competition /that/ much

Re: Why Single Sign on Sucks

#52

Post by paranoidrobot »

hinkley wrote: post #18
deergomoo wrote: post #3

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…

As the de-facto Security team - the main concern for me isn't so much "lock everyone out immediately" aspect, it's the reduction in the number of sets of credentials for people. It is a benefit in the onboarding/offboarding process, too - it's one less thing you need to go in and manually turn off accounts.

People suck at remembering passwords, and even if you go and give them Password Manager tools like 1Password/Lastpass/whatever, they'll still tend to re-use the same password they use for their personal email, and that random service that recently got pwned.

It's worse when they have credentials like AWS IAM Keys that are while not difficult, are inconvenient to rotate. Those are likely to just sit around on someone's machine and get leaked inadvertently in logs or test code.

Re: Why Single Sign on Sucks

#53

Post by dlp211 »

toastal wrote: post #48
Aeolun wrote: post #33

Earlier quoted context omitted.

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.

It would also help an adversary that only needs to know your one password.

Which is why we also use 2FA. You are using 2FA right?

Re: Why Single Sign on Sucks

#54

Post by paxys »

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 the examples they mention are all just badly configured applications, which can easily be fixed.

Re: Why Single Sign on Sucks

#55

Post by alar44 »

seiferteric wrote: post #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…

VPN is easier to set up, manage, and troubleshoot. Connect to LDAP, set up groups, flip the switch, done. You'll have to use it for vendor or 3rd party access anyway, so may as well use it for the rest of the org.

Re: Why Single Sign on Sucks

#56

Post by toastal »

zaptheimpaler wrote: post #16

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…

What do you get out of having a GitHub app on your phone? I've never needed or wanted to think about pushing code from my phone. Things I may want to know about are already emails I can reply to (or the mobile website if an emergency).

Re: Why Single Sign on Sucks

#57

Post by mooreds »

hsbauauvhabzb wrote: post #37
smitty1e wrote: post #13

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

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.

Re: Why Single Sign on Sucks

#58

Post by adontz »

GitHub's SSO if it's not Enterprise managed accounts sucks. Thus the example is extremely unlucky.

Industry standard is that service provider gets identity from identity provider and provisions an account with that identity. So that if I log in to Jira as john.smith@example.com I'll have john.smith@example.com username.

What GitHub does is it links enterprise identity to personal account. So I have to log in twice (and honestly it's already not an SSO at this stage) first time I log in with enterprise identity and then I log in with personal account. So I log in as john.smith@example.com, then login as HugeDick53 and then I'm visible as HugeDick53 and john.smith@example.com identity vanishes from view.

GitHub's justification is that contributions on enterprise projects should be visible on personal accounts. However, from administrator's point of view entire system + UI issues make this type of so called SSO completely unusable. Nobody in company has any idea who is HugeDick53.

On the other hand Atlassian products provide true SSO. Not the most sophisticated one, but at least it's SSO.

Re: Why Single Sign on Sucks

#59

Post by gkop »

pyrale wrote: post #47
gkop wrote: post #35

Earlier quoted context omitted.

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?…

(I made some edits to the previous post, as I figured out you may have talked about people working with you rather than clients) > I have no issues getting my enterprise customers to configure SSO, so there's no practical reason for me to support password login. I'm not really sure what you mean when you say SSO. We use Google workspace at work, and use the sso in several of our products. Still, since workspace admin…

We certainly agree on the importance of making it easy and convenient for the users to behave well. The traditional example here is onerous password requirements that lead to post-it notes.

> Still, since workspace admin prompts us to relog every damn time, some colleagues use the service account to perform workspace actions. That's a hole of course, as the service account is not supposed to be used for user actions, but it's also more convenient.

This is a great point that I hadn't considered. Thank you!

Re: Why Single Sign on Sucks

#60

Post by mooreds »

deergomoo wrote: post #3

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 one has done that.

I think that a more fruitful approach would be to go the webauthn path, and tie into the browser/OS for support (as mentioned in the article). Boom, deployment solved (https://caniuse.com/?search=webauthn has the list; it's most major browsers on mobile and desktop--the only one missing that I'd love to see add it is FireFox on Android).

Now you need to tie into the application and I don't want to diminish that effort. But many apps use libraries or auth servers, so your surface area for deployment is far smaller.

Post reply on HN