[HN Gopher] Why Single Sign on Sucks
___________________________________________________________________
Why Single Sign on Sucks
Author : benarent
Score : 62 points
Date : 2022-03-11 21:13 UTC (1 hours ago)
(HTM) web link (goteleport.com)
(TXT) w3m dump (goteleport.com)
| bvrmn wrote:
| SSO sucks nothing in compare with TOTP-incompatible "please scan
| QR" mobile auth. With uniq app per service.
| politelemon wrote:
| Sendgrid does something similar. You can't use TOTP, you have
| use Authy specifically for their special 7 digit code. It's
| infuriating and they don't care.
| deergomoo wrote:
| 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.
| Aeolun wrote:
| 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.
| toastal wrote:
| It would also help an adversary that only needs to know your
| one password.
| dlp211 wrote:
| Which is why we also use 2FA. You are using 2FA right?
| throwawayboise wrote:
| That's centralized identity management, not single-sign-on.
| Single-sign-on is/was supposed to mean you sign on once. I've
| never seen it actually work.
| hinkley wrote:
| SSO is the source of truth, and centralized identity is the
| system of record. They go hand in glove. It's not a non-
| sequitur so much as a tangent.
| gkop wrote:
| for the benefit of others (I had to search it):
| https://www.linkedin.com/pulse/difference-between-system-
| rec...
| Jenk wrote:
| SSO can be both Single Sign-On, or _Same_ Sign-On.
|
| The latter is the LDAP integrated thing - (re)using the same
| credentials for multiple/disparate services, controlled
| centrally.
|
| The former ("true" single sign-on) is logging in once and
| accessing everything from there.
|
| FWIW there are single sign-on services out there. Okta is
| used by my current employer, I log into the Okta portal and
| it has links out to all of the services it supports from
| there.
| Spivak wrote:
| Yeah, the manifestation of "LDAP Integrated" still means you
| have to sign into every single service, it just uses the same
| credentials.
| hinkley wrote:
| 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 entire network in the time
| between when their boss says, "Hey, can we talk" and the office
| door goes 'click', then centralized credentials at least can be
| somewhat atomic. Session caching, to make this arrangement
| perform, undermines that immediately of course.
|
| On the other hand, when someone accuses you of something way,
| way out of character, we learn as we mature that it's fairly
| likely this person did some mental arithmetic that went, "What
| would I do in this situation?" and that popped out. The person
| who accuses you of stealing their mug at the drop of a hat may
| have a passing fancy with stealing mugs themselves.
|
| So we learn that in perhaps 95% of cases, non-sequitur
| suspicions are either the product of the mind of a suspicious
| person, of someone who is jaded by bad experiences (steal
| someone's lunch enough times and they will start accusing
| random people), or of someone who deep down knows they kind of
| deserve whatever is about to happen.
|
| So it troubles me a bit how quickly the C Suite prioritizes
| having a giant switch to lock people out.
|
| I've developed a nervous habit of any time I hear someone
| getting 'talked to for a second' or suddenly a bunch of 1:1s
| show up, of cleaning up my computer a little bit, then my desk.
| Rarely do I have anything that is worthy of cleaning up, but it
| doesn't hurt and gives me somewhere to put some of that feeling
| of impending doom. If I had a bad experience of having to clean
| out a messy desk, I don't remember it very well, but I'm sure
| it's happened. I know the first time I quit I learned not to
| try to take everything home on the last day. Somehow my stuff
| always ends up being bulkier than I estimate.
| Johnny555 wrote:
| _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._
|
| Proper offboarding protects you too, not just the company. If
| you leave the company and someone compromises one of the 27
| hard-coded credentials left behind on various machines and
| services, then it puts you under suspicion.
|
| In companies where I do have hard coded creds (including
| shared passwords), when leaving a company, I compile a list
| of all of them and send it to my manager and tell them to
| make sure they are all disabled.
| ghaff wrote:
| Yep. It's like sharing passwords to important personal
| accounts more generally. Sure, the main reason you don't is
| that stuff can happen in relationships and people can end
| up doing things you didn't think they would. But a
| secondary reason that if something _does_ happen in an
| account that you 've shared a password with someone, it's
| hard not to have at least a glimmer of suspicion.
| paranoidrobot wrote:
| 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.
| IncRnd wrote:
| > 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.
| phh wrote:
| > 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
| [deleted]
| feoren wrote:
| > Employers also see trusted employees smile and leave for
| competitors even after signing that they would not do that.
|
| 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. Where else are
| they going to go work, but companies with similar
| operations? An ecology management company fires and
| ecologist and they clutch their pearls when that ecologist
| goes and works for another ecology management company,
| instead of McDonalds!? _Gasp!_ The nerve of that person!
|
| Don't want your employees to go work for a competitor?
| Don't treat them like shit.
| IncRnd wrote:
| > 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 ecologist goes and
| works for another ecology management company, instead of
| McDonalds!?
|
| You can word it that way, but what can and does happen is
| that employees leave and steal confidential processes or
| information to boost their own value at a competitor.
| Many people agree with you, until they start their own
| company and theft happens to them, draining their work
| straight to a competitor.
| paxys wrote:
| 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.
|
| Also the examples they mention are all just badly configured
| applications, which can easily be fixed.
| XorNot wrote:
| 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.
| csben wrote:
| 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.
| throwawayboise wrote:
| 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.
| derekp7 wrote:
| I see this in situations similar to sudo where you need to
| make sure it is the same user that signed on when elevating
| privileges, vs letting in anyone who sits down at an unlocked
| user's terminal.
| pyrale wrote:
| I would say that's not really a SSO issue so much as it's an
| obnoxious session duration policy.
| csben wrote:
| 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.
| Spivak wrote:
| Which is silly because if you do that you're basically
| admitting that your SSO isn't fulfilling its promise of
| identifying the user. If you are having the thought, "what if
| the user I authed isn't the user anymore" then you should be
| reauthing them for any service at that point.
| seanp2k2 wrote:
| Almost as fun as when TSA uses logic like "we thought you
| were going to hijack a plane using those nail clippers, but
| now that we've made you throw them away, you can board with
| no further scrutiny! Crisis averted!"
| sitzkrieg wrote:
| downstream SSO consumers sure do like to expire em quickly and
| idk why. using jumpcloud SSO with several sites is not painful,
| aside from things like github hiding a tiny line saying "sign on
| w sso" and making the tables where stuff would be shown empty so
| it's initially easy to miss you're not fully signed in. like just
| kick me to full sso button screen instead of showing a bunch of
| stuff i cant interact with until i click that banner
| jFriedensreich wrote:
| not a great article. apart from multiple wrong or missing words,
| the section about browser profiles is just plain weird and
| ignoring firefox premiered this without any tracking motivation
| and also with different set of problems in mind. many sections
| read as if the author did slightly superficial or slightly off
| research.
| wereHamster wrote:
| > While it's possible to create cookie with credentials, this
| should be avoided due to all the possibilities of CSRF Attacks
|
| This is no longer an issue, if you use SameSite=Strict, Secure,
| HttpOnly cookies.
| gkop wrote:
| 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 security issues with the real
| life corporate SSO experience described in the article. For
| example, users habituate to frequent authentication requests, so
| they click through them blindly, which opens the door for
| phishing.
| Aeolun wrote:
| 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.
| seanp2k2 wrote:
| 1. Try passwords until you get locked out
|
| 2. Engage with IT to unlock
|
| 3. Reset password flow
|
| 4. Iterate on new password as the complexity requirements you
| fail are slowly revealed to you
|
| 5. "Password cannot be the same as previous n passwords"
|
| 6. End up with an even more forgettable variation
|
| 7. Sign in again across all your now-invalid sessions across
| a dozen apps and devices.
|
| 8. Apply liberal amounts of 2FA + push-based and email or txt
| confirmations to the above for extra hate from users.
|
| 9. Repeat forever because obviously there is no better way to
| do this, but GraphQL and NFTs are going to save the world,
| let's work on those instead!
| gkop wrote:
| Don't get me started...
| smitty1e wrote:
| 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.
| hsbauauvhabzb wrote:
| 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
| EGreg wrote:
| Why don't people just use webauthn?
| hsbauauvhabzb wrote:
| This is incredibly naive, you have to consider support of both
| applications and help desks, and the cost of those.
| zaptheimpaler wrote:
| 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
| everything all over again to a different broken solution like
| client certificates or biometric auth again in a few years.
|
| In 5 years, someones OS is compromised and their client
| certificates are hacked. Or some kind of centralized storage for
| client certificates is hacked, or a certificate authority is
| hacked. Industry will then decide "omg client certificates are
| insecure" and we can migrate to some other crap again.
|
| Or we can all move to SSO. Even if we had perfect once a day SSO,
| what if an employee leaves their laptop unattended? One day that
| will happen, some company will get hacked, and then "once a day
| SSO is insecure"..
| Johnny555 wrote:
| _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 locks are supposed to
| protect from, my company enforces a 5 minute screen lock. I
| used to use a bluetooth screen lock that would lock my screen
| immediately if I stopped away from the computer, but the
| company now won't let me use that app because it has the
| capability to automatically unlock when I come back (though I
| don't use that part).
| zaptheimpaler wrote:
| > 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.
| seiferteric wrote:
| 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?
| alar44 wrote:
| 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.
| [deleted]
| 0xbadcafebee wrote:
| This is how I login to SSO today at work: Login username is
| cached in browser. Password is auto-filled-in by my password
| manager, which is in turn unlocked for a period of time when I am
| logged into my desktop. I hit "Log In" button. Backend does
| magic. An app pops up on my phone. I supply my fingerprint.
| Authentication is approved, and my browser is now logged in.
|
| Same pattern works for logging into AWS from the console. My
| password manager keeps the username and password. Every time my
| AWS temporary session token expires, AWS CLI asks saml2aws for a
| new session token. Saml2aws gets user/password from the password
| manager, logs in. If session has expired, I get a pop-up on my
| phone asking me to log in. I supply fingerprint. Authentication
| is approved, and saml2aws creates a new session, passes it to AWS
| CLI, and I'm off to the races.
|
| I can control exactly how often I have to enter in a password (to
| unlock my password manager), and the site administrator
| determines how long my sessions last. Is it _super duper secure_?
| No. But is it better than me typing my password, hitting submit,
| getting a text message, and typing a code in? Absolutely.
|
| The same pattern can totally work across multiple sites. The
| standards just need to be changed to allow it to happen. This
| isn't a technical problem, it's a political one.
| SteveNuts wrote:
| The problem is it's much more complex to manage N users in N
| applications, having a central location to onboard and offboard
| your users is a huge boon to IT departments. The convenience
| isn't for you as the user.
| Spivak wrote:
| That's central identity management -- related to, but
| fundamentally orthogonal to sign in once be signed in
| everywhere.
|
| SSO without central identify management would be _weird_ but
| also very possible.
| mindslight wrote:
| Sounds ripe for some additional automation involving a
| synthetic fingerprint mounted on an actuator, and some image
| recognition to know when to lower it onto the phone.
| gkop wrote:
| 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)
| pyrale wrote:
| 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
| recipe to have people build backdoors in their own security.
| Good security is only as secure as it is convenient for
| users.
|
| When I was working in banking, people had physical card
| readers that would identify them. Of course, some people
| still forgot them sometimes, but it was also necessary to get
| out of the desks.
| gkop wrote:
| 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?
| pyrale wrote:
| (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 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.
|
| Another example, of which I'm guilty, was my previous
| work's VPN 2FA policy, which my team conveniently skipped
| with a script doing the oauth call. Of course, not
| everyone did the script properly (because prompting for
| your password takes a couple more lines), and so some of
| us may have had their credentials in the bash file.
|
| This kind of shortcuts is hard to avoid for technical
| users, and so the golden rule for security in my opinion
| is that it should be easier to do the right thing.
| Unfortunately, each person has a different definition of
| friction, so it's not an easy topic.
|
| > What do you mean by invasive security practices?
|
| It's obviously a personal criterion. To me, invasive
| starts when people want to get in my phone. It's not
| really arbitrary, since my phone is a piece of garbage
| that has no security, but it's a personal thing since
| others may prefer to have a phone solution.
___________________________________________________________________
(page generated 2022-03-11 23:00 UTC)