Tell me more ×
IT Security Stack Exchange is a question and answer site for IT security professionals. It's 100% free, no registration required.
up vote 7 down vote favorite

I got shot down on ServerFault recently for suggesting that SSO can be less secure than having different credentials for each service. What are the arguments against SSO?

share|improve this question
Providing a link to the serverfault answer that contains your comments, and responses to them, to provide additional context. NOTE: To view all the comments, after visiting the page click: "add/show more comments" below the last comment. – blunders Jun 6 '11 at 15:35
@blunders - Thanks. Just to note that most of the comments are not about SSO, unfortunately I can't link to individual comments, but I guess you'll get the gist from that. – Jack Douglas Jun 6 '11 at 15:43
2  
I think it isn't helpful to stoke the fires via how you ask the question.... Could you balance it a bit, and edit in link that blunders dug up? Most helpful would be some more context for the sort of environment you're evaluating SSO for, the threats and assets you're dealing with etc. – nealmcb Jun 6 '11 at 20:37

2 Answers

up vote 6 down vote

Two views:

Corporate:

Whether you have control over all the machines, or at least the central auth server, you're better off with SSO. One place to hire employees, one place to terminate them, one set of credentials they have to worry about. Individual server compromises shouldn't leak credentials. Users are less likely to get annoyed, forget passwords, and use horrid patterns of passwords especially when the 7 different computers they have to access start hitting their password change periods at staggered points.

In a company environment, you want one point of authentication.

The Wild Internet

Spoofing / phishing is a bigger concern. Privacy becomes a concern. A third party knows everywhere you log in. Compromise of that 3rd party compromises all your accounts. The benefits of one identity, one login have to be weighed against all those. When you get duped into a fake login page from your web forum and it links to your email, and hence your bank, things may get ugly.

For the ServerFault guys, there's no question that they want that on their network. For the world at large, there's a big bit of trade-off to be had.

Edit to address commments

  • Submitting one's login credentials to a 3rd party service is the antithesis of single sign on.
  • In some cases, it does make sense to provide users with multiple accounts. Many wise system administrators have their normal operations accounts and their elevated privilege accounts. At the same time, this is still an SSO system. It is often the case that a central authentication server handles the multiple accounts.
  • In regards to password sharing, I consider that a poor argument against SSO. In any case where access to something should be shared, it should be done with different credentials. While we have to accept that there are some systems out there that need sharing and do not implement the ability to assign rights, this should be addressed by altering the system whenever possible.
share|improve this answer
2  
@Jeff - I wonder if the lines are getting blurred: I recently found a user had given a 3rd party email service their corporate logon so they could act as a proxy for their mobile device to see their exchange (OWA) emails. – Jack Douglas Jun 6 '11 at 15:47
@Jeff Ferland: Why would it not make sense for the "Corporate" world to require employees to have passwords grouped by the level of risk related unauthorized access? At the very least this might lead to increasing the employee's understanding of the levels of risk presented to the company, and the possible spaces in which threats exist; which in itself would be of value in my opinion. – blunders Jun 6 '11 at 16:02
1  
@JackPDouglas: In my opinion, if the user shared their corporate authentication credentials with a 3rd party that should be a direct violation of corporate policy; reason being they shared the everything required to authenticate: domain/user/password/etc. The fuzzy area is when a chained-exploit uses the password of a non-corporate account as an attack vector; very common, and corp-policy should ban the reuse a of corp-password ever, anywhere. The real issue to me is corp's unwillingness to require employees to have passwords grouped by the level of risk related unauthorized access. – blunders Jun 6 '11 at 16:24
@blunders: Interesting point about password reuse - I dread to think what the full extent of the problem is here. Problem is that there is absolutely no way of enforcing that sort of ban, and unless the user tells you, even after a breach there is no detective work that will show you how the attacker got hold of the password. Interesting point about risk-related passwords and "increasing the employee's understanding of the levels of risk", thanks. – Jack Douglas Jun 6 '11 at 16:33
1  
@blunders, good point. Maybe part of the problem is that corporate systems do not allow a separate password for access to some subset of the corporate websites. I frequently run into cases where I would like to share my password with my administrative assistant, to perform a limited task (and one that is reasonable to trust my admin assistant with), but the corporate system doesn't allow me to do that safely (because I'd have to share my password for everything, and because the web site does not permit delegation). When a security system makes it hard to get work done, people bypass security. – D.W. Jun 6 '11 at 18:10
show 4 more comments
up vote 2 down vote

Imho the biggest concern with SSO is the sheer impact of a password breach, simply by factoring up all possible service accesses.

Otoh the younger history has shown that password reuse is more the rule than the exception. And SSO can also be used to enforce e.g. stricter password policies (use one password, but use it in a secure manner) or even enrich it with stronger authentication.

So I guess it all depends on the implementation ...

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.