Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

We were discussing to implement single on in our web application,right now after analyzing we came to know that the following were the advantages of single sign on authentication.

Advantages

  • Users select stronger passwords, since the need for multiple passwords and change synchronization is avoided.
  • Inactivity timeout and attempt thresholds are applied uniformly closer to user points of entry.
  • It improves the effectiveness/timeliness of disabling all network/computer accounts for terminated users.
  • It improves an administrator's ability to manage users and user configurations to all associated systems.
  • It reduces administrative overhead in resetting forgotten passwords over multiple platforms and applications.
  • It provides users with the convenience of having to remember only a single set of credentials. This also improves security as users find it easier to remember their credentials and do not have to write them down, allowing for a more efficient user logon process.
  • It reduces the time taken by users to log into multiple applications and platforms.

What disadvantages exist when implementing single sign on technology?

share|improve this question
1  
I'm pretty sure, the avarage user would not use a better password for a single sign-on solution. Most don't care and wouldn't even know the difference; to them it is just another password box they need to fill in. –  Jacco Dec 10 '12 at 11:58
add comment

4 Answers

up vote 5 down vote accepted
  • Single point of failure

  • Single high-value target (attracts more attackers)

  • Necessary information disclosure between trusting site and SSO authority

  • Side channel attack against authentication step (theoretically; implementation dependent)

  • Lack of control over your user list

  • Yet another interface to maintain (added complexity)

  • You may never know how secure your system is or if there is a breach

  • Added cost

These are all off the top of my head. I imagine someone has compiled a canonical list somewhere.

share|improve this answer
1  
Essentially the problem boils down to the fact that you're handing your security mechanisms to an opaque 3rd party. This is, simultaneously, single sign-on's biggest advantage and disadvantage. You sacrifice certainty about security for a range of other security benefits, and a few other benefits (ease of use, implementation overhead reduction, etc.) –  Polynomial Sep 24 '12 at 6:00
1  
Could you supply some references for these? This reads like a list of assertions, some of which are highly debatable. SSO absolutely does not lead to single point of failure or a lack of control, and most studies indicate that it costs less rather than more. –  Mark C. Wallace Dec 10 '12 at 11:48
1  
@MarkC.Wallace You ask for a list of references but you then assert an absolute that is innaccurate. It absolutely can be a single point of failure if the IdP fails. Key word being "can". It can lead to a lack of control if you defer authentication to another party. –  SteveS Dec 10 '12 at 18:28
    
Let me try to restate my point in a less argumentative fashion and then yield the question. Our SSO is implemented in a fashion that does not create SPF, and does not lead to a lack of control. I believe that some of the disadvantages listed above are failures of implementation, rather than of SSO. One can implement anything badly. If I were in the OP's shoes and trying to brief my management, I'd be careful to brief only those disadvantages which remain in a competent implementation. My apology if I seemed fractious, I did not mean to insult. –  Mark C. Wallace Dec 10 '12 at 18:36
    
+ joiners / movers / leavers is not always handled properly by SSO, e.g. you end up with provisioning processes for some systems and not others. –  Callum Wilson Dec 10 '12 at 22:10
show 1 more comment

This started off as a comment to Tyler's answer but running out of space.

Yes, if you implement it badly, then there will be bugs which can be exploited - but there are only 2 pinch points where SSO is different from seperated systems in this regard - when transitioning from the SSO site into the application site, and when terminating an SSO session (and hence sessions on the trusting applications).

Single point of failure

Only if it's badly implemented.

Necessary information disclosure between trusting site and SSO authority

How are you exposing more information to the trusting site? Indeed, there is much less opportunity for exploiting the application when it does not handle the authentication itself.

Lack of control over your user list

How? If you control both your applications and the SSO then why do you have less control?

Yet another interface to maintain

Defining interfaces and appropriate isolation between system components is good practice. SSO merely forces you to apply this practice. I think that's a benefit. Indeed maintaining a single implementation of the code for authentication rather than multiple ones should reduce complexity and cost.

You may never know how secure your system is or if there is a breach

How is this different from standalone systems?

Added cost

As per point regarding interface - it shouldn't add code complexity, nor does it require additional hardware. The only added cost I can think of is the need for an additional SSL cert - which is hardly that much.

If you are handing your security mechanisms to an opaque 3rd party then most of the points are valid - but not if you are implementing the system yourself.

There is a slight performance overhead with redirects for users only accessing a single application - but not huge.

share|improve this answer
add comment

You don't say if the scope for SSO is intranet or internet. If it includes internet then I've got a lot of love for SAML 2.0 compliant sites, however there are some disadvantages of SAML2.0 and SaaS sites:

  1. A lot of SaaS vendors (service providers) do not support all the SAML 2.0 assertions, e.g. joiners/movers/leavers assertions so you don't get all the benefits of SAML2
  2. Agreeing the SAML2 assertions with a SaaS vendor can be quite hard work to begin with.
  3. if the SaaS site requires federated SSO for, say staff users, and then continued access when the staff leave then you get into some horrible dual mode authentication that weakens the overall solution. i had this with a payslip system where staff are meant to continue to have access once they have left the company. i.e. where the IdP (identity provider) is the internal staff directory.
  4. SAML2 compliant products (for your side of the firewall) are expensive and dominated by one company (so difficult to negotiate price)

other than that - if you can get all SaaS sites working for your org with SAML, linked to your own identity store then you will have knocked out a huge risk, especially since users choose the same password for all corporate logins.

The worst thing you can do (mentioned above) is cook your own SSO scheme.

share|improve this answer
add comment

In addition to @tylerl's answer:

  • If you leave your computer for a minute, an attacker can abuse your account on all connected sites.
share|improve this answer
    
Citation or reference please? This is an assertion without evidence. I'm not sure that I agree (either that this is true, or that this is different from a non-SSO system). –  Mark C. Wallace Dec 10 '12 at 11:49
    
@MarkC.Wallace Why do you need a reference? It's plain as day. Single-sign-on means that you sign in to all connected websites by signing in once. If you leave your pc, all connected websites can be abused. With multiple accounts for multiple websites, only the websites that you explicitly signed in to could be abused. –  Luc Dec 10 '12 at 13:39
    
I need a reference because you're making assumptions that aren't accurate. SSO can be implemented in a variety of different ways, some of which are vulnerable to that attack, some of which are not. You might want to check [NISTIR 7817] (fiercegovernmentit.com/story/…), or FIPS 201, or other references. –  Mark C. Wallace Dec 10 '12 at 14:09
    
@MarkC.Wallace The core thing about SSO is that you enter your credentials once to get signed in everywhere. What implementations prevent against this and are still SSO? If you have to enter your credentials multiple times it's not SSO anymore. –  Luc Dec 10 '12 at 14:27
    
HSPD-12 is implemented as SSO, but whether you need to re-enter your credentials depends on a risk based decision. The Relying Party can decide that the credential is stale, or that the requested function implicitly needs a fresh authorization. Having said that, I'm going to yield this point. I think that I'm making assumptions that I found vague in the original question, but perhaps that's not justified. –  Mark C. Wallace Dec 10 '12 at 14:48
add comment

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.