People overwhelmingly recommend SSO. Isn’t that lowering the security level? If that single account gets taken over, the attacker has access everywhere else too.
Some places let you configure SSO+2FA, which helps; but in most cases clicking a social login button gets you full access.
And speaking of a single point of failure, cloud password managers look even worse[1].
SSO + 2FA is more secure in practice than letting people create/manage their own accounts at every service. Because:
- You can force a password policy centrally (minimum 12 char + uppercase/lowercase + number etc), for every service the company is using that supports SSO.
- You can force 2FA, again for every service the company is using that supports SSO.
- You can disable an account immediately from the central admin panel as soon as you notice an account is stolen.
- When the employee leaves the company, you can delete their account centrally from every service, so there are no inactive company accounts registered to various services.
The first minimum char counts rule is great. You increase the entropy exponentially with every added char.
But the second part when you make rules about each individual char, then you are actually decreasing entropy. The space of possibilities actually shrinks every time a rule defines what a char must or mustn't be. An attacker now knows that certain things are guaranteed, and can tune their brute force algorithm to expect a big ascii letter, a large ascii letter, a latin number, an ascii special char. They now have a much smaller search space than before, when each char could be any utf8 char. You're basically leaking exploitable information about the password by having character rules.
The alternative in practice is not all utf8 characters, the alternative is lowercase letters. If there are no rules that require uppercase and alphanumerics, or length, then many people will use passwords that are easy to type, and short, and not impose security difficulties on themselves. The alphanumerics + case rule is addressing human behavior, and effectively does increase the search space (by a lot) for most people, not decrease it. It would be nice if most password entries could detect other utf8 chars and allow them to substitute for cased alphanumerics, or if longer passwords could relax the rules. The point is to meet a threshold of security against attackers, and the blanket rule does that but ignores some viable and convenient alternatives.
> - You can force 2FA, again for every service the company is using that supports SSO.
This can also be a way to balance security and user convenience, which should not be underestimated.
If a user has to do the MFA dance (Duo Pushes, TOTP tokens, ...) once a day for a dozen different services, users will rightfully riot and start looking for workarounds of questionable security. On the other hand, you could have one MFA dance in the morning to get your keycloak session, it is kept alive by normal usage and then it doesn't bother you anymore for the day. Much lower friction.
Another thing is auditing and analysis. With central logins, you need one service with good audit logging, and you need to understand and alert on one log if a user suddenly tries to login from another continent, hundreds of times a minute. Some of these services have this built-in.
While the single point of failure (especially for browser cookies) can be an issue, handing authentication and associated bookkeeping to an entity that does that, instead of plugging your own essentially least viable product level auth on top of every service is a win.
If everyone did authentication well, then centralized IDPs might be questionable from a computer security perspective. But most aren't doing it well.
On top of that, humans generally work best if they don't have to remember lots of truly random passwords. I.e. in realistic settings, there's a maximum of expected passwords either way. And the true gain of having dedicated auth everywhere is minor.
There's some consideration for things like FIDO/WebAuthn/PassKeys, but they mostly just shift the issue from a single provider in cloud, to a single (hardware) token.
Harder to copy than browser cookies, but still a single point unless it's combined with MFA.
With SSO, the party running the SSO decides what the authentication policy is.
For example, where the authentication request is coming from (on-site, managed device), what methods are being used (hardware second factor, Authenticator app).
These are all things that the SSO can check at time of authentication, before a token or session key gets issued to the user. Also, all of these things can be checked again when doing any auth flows for the various linked services.
So with stolen SSO credentials, they might be worth diddly squat to you if you didn’t think to also be on-site or on a managed company device (physically or virtually).
Sure, password managers are a SPoF, but in the event of a keylogger installed on the computer of someone with elevated access, you're screwed either way, password manager or not. Still, here password manager + 2FA could have helped, unless... 2FA recovery codes went through the clipboard at a time when the keylogger was watching the system clipboard... Next time I activate 2FA, I'm writing that down, in the dark, in a restroom, fold it, put it in a safe.
Generally people have a recovery option (“Forgot Password”) which routes to the same email, meaning it’s effectively already a single point of failure.
But it’s generally a well-secured one (2fa, ip monitoring ). So in effect we’re not making it more of a single point of failure, we’re just removing the various other means of attack by removing site-specific identities (passwords)
Some places let you configure SSO+2FA, which helps; but in most cases clicking a social login button gets you full access.
And speaking of a single point of failure, cloud password managers look even worse[1].
[1]: https://thehackernews.com/2023/02/lastpass-reveals-second-at...