The following quote is from the CompTIA Security+ guide:
Single sign-on enhances security by requiring users to use and remember only one set of credentials for authentication.
How is that enhancing security ? The way I see it is that it's rather a single point of failure.
Isn't it more secure to have multiple different passwords for different accounts/services ?
The idea with a good single sign on is that there are fewer places for your credentials to be compromised. There are three reasons to use different passwords, first, because each unique place that stores your password (hopefully hashed) is another place it could get compromised. Second, because if your password is compromised, any other account using it would need to be updated and that is hard to do. Third because if your password is compromised, they could access multiple accounts if they were shared.
SSO is a great advantage for the first two. A good SSO system should only store your account credentials in one location (which is hopefully far more fortified). All authentication is done against this one store. If your account is compromised, rather than having many places to update, only one password has to be changed and one account locked down.
It doesn't particularly address the third concern, but it makes compromise less likely in the first place. Additionally, depending on the account, different passwords don't necessarily act as much of a barrier. There are plenty of reported examples of attackers using one compromised account to chain from account to account until they can get to the actual account they want. (For example, if they can access your e-mail account, then they can use password resets.) A good system of reporting compromises and allowing for the account to be locked down can make a decent help towards mitigating the risk though when suspicious activity is detected.
The argument that completely unique credentials may be more secure than a good SSO setup is possibly valid, but in the real world, most people reuse credentials. SSO mitigates much of the risk of this behavior while still allowing the convenience people want.
The more passwords the user has, the harder they get to manage.
They will forget their passwords more frequently, which means they will need to contact a helpdesk or an automated system to reset it. Such password reset procedures are often vulnerable to all kinds of different attacks. Helpdesk personnel can be tricked through social engineering and the emails sent by automatic reset systems can be intercepted.
The alternative would be when the user would use the same password for everything, which is a really bad idea, because a password compromise in one system would compromise all systems. It might seem like SSO is doing exactly the same thing, but most SSO systems work in a way that the applications which use it do not know the actual password of the user. Usually the user only authenticates to the SSO system which then sends a one-time use token to the user and the application.
I've advocated for using SSO on our intranet applications to increase security. In theory, it doesn't. Many different well secured databases, each with a random password with no relation to any other passwords a user has, is more secure... in theory. But in practice, people reuse their passwords and not all passwords are stored following best practices. This means that the access to your strongest system is protected by the security of the weakest system. By using SSO, we have a single system that we can better ensure follows best practices.
There may be other options, such as forcing passwords to be different, but I've yet to see one that works well (even a different password doesn't mean much if it is My$secret1, My$ecret2, My$ecret3, ect., but how are you going to determine how similar passwords are in system number 5 if you have properly hashed and salted passwords in systems 1 through 4).
To think of it another way, putting all your eggs in one basket seems silly in general, but we have a quantumly superimposed set of eggs, where if one breaks, they all break. In such a case, it is better to put all your eggs in your most shielded basket.
So one aspect missed a little in this post is that aspect of adding additional factors of authentication to SSO. For example lets say you have 10 sites you login to, all these sites only take username password, which is the easiest to understand and crack. As another poster mentioned a good SSO will set large randomized passwords for the login, I am thinking 32+ characters, randomized with special characters, that can then be changed every 30 days. This is something a person would never remember or want to type, you do this with regenerated random passwords for each site. So you still have the fallibility of username password but at least now it is as secure as it can be. On the other side, the IDVault the user logs into can now be protected with 2 or 3 factor authentication, so using bio or token or both to access the IDVault is much more secure than non-SSO username passwords to each site.
In the end it is a matter of protecting users from themselves, if you required long, hard to break passwords they will store them in a spreadsheet or a paper note 99% of the time.
Of course as a previous poster mentioned this does open one point of failure, this in itself can be mitigated but never completely factored out. In the end as a security professional you have to evaluate the risk of the failure(mitigated or not) and the risk of user defined, easy to remember passwords. To me the answer is obvious but that is my opinion and may not be yours.
