Paid Advertising
web application security lab

CRYPTOCard - One Click And You’re In And So Am I

I stumbled accros some CRYPTOCard promotion today and I really thought it was worth a quick post. The concept of single sign-in is a tough one. It really makes sense from a consumer point of view, but it’s bad from a security perspective, although most people don’t really get why. I have a long history with authentication systems so this one is one that is probably worth discussing.

When I attempted to launch a consumer product that enabled single sign-on at one point the first people we went to talk to were banks. It makes sense, the people who have the most to loose and are willing to sacrifice some usability for security are the people who have to insure your money. So we went and talked with them and they said that they were unwilling to enable single sign-on because they felt that someone would hack into the back end and steal whatever underlying technology required to get access to other accounts.

Right sentiment - wrong security hole.

The problem isn’t that the backend is insecure. Even though 70% of hacks are internal, I’m much more concerned about what can be done from the outside. You can mitigate internal risks by proper access controlls (the same kind the banks use with vaults with keys in them, blah blah). The problem is really on the front end.

Let’s say has a website that you authenticate to. By virtue of single sign-on you are now authenticated to Now suddenly, CSRF via XSS in that exploits and would normally fail on (becauuse previously I wasn’t logged in there) now functions. Worse yet, the article talks about giving access to intranet sites, etc… well that just makes our JavaScript intranet port scanning technique even more powerful because now I don’t even have to muck about with brute forcing authentication methods - I’m in without even trying.

The peril in single sign-on is that the least common denominator dictactes a large portion of the security for all members of the authentication network. Sure you can mitigate certain risks by using session tokens, but anything that would have been protected by a tiered authentication model now dissapears. Not a good situation to find yourself in if you are

9 Responses to “CRYPTOCard - One Click And You’re In And So Am I”

  1. maluc Says:

    Any sort of security will eventually be broken, putting all your eggs into one basket is like taping a Kick Me sign to your own back _-_ ..

    In theory, aggregating all your sensitive data into one ultra-secure location makes alot of sense .. but as you pointed out for web-based applications, thanks to XSS it is likely even less secure than fragmented data.

    The point being - the more i learn about XSS and the future of internet antisecurity, the worse i sleep at night :T .. i don’t think this WWW (read: wild wild west) frontier will ever be tamed.


  2. Omer Taran Says:

    I think you got it all wrong. It has nothing to do with SSO, it has to do with your trust model.
    what you described is a situation where you trust someone else’s security as if it were your own.
    why would you? and if you did that already you have to make sure he’s as secure as you are.

    SSO is great for internal use, if implemented securely and properly. Trust is a big issue between organizations, but has nothing to do with SSO. would you trust a certificate someone else issued (say verisign)? one can hack the CA/RA and create a false certificate. does that mean PKI is flawed? no. it means your trust model is not what it should be.

  3. RSnake Says:

    Hi, Omer, if I log into one place and I recieve access to other applications as the article describes (as Passport worked for instance), that’s an issue. I’m not sure what you’re describing since you didn’t include concrete detail, but as the article described the system it’s highly flawed in terms of CSRF.

  4. Omer Taran Says:

    RSnake, what you’re saying is correct. Only I don’t think that’s an issue. IF scenarios are bad for security.
    if the alternative for a security token SSO is a password based authentication would you still support the password instead of the SSO? sure there are exploits. but saying that SSO is not good because it creates a single point of failure is overlooking the fact it’s giving you a single point to defend, which is easier. My point is that SSO is niether good nor bad. it’s how you implement it and the underlying assumptions which make it good or bad.

  5. maluc Says:

    That would be a correct assumption Omer, if internet SSO systems worked like physical security .. but it doesn’t.

    If someone builds an ultra-secure building with only one door to enter (Single Point of Entry) .. that does indeed make it much easier to defend from unauthorized intruders.

    But in the intertube land, having a Single Sign On means when you’re logged into one of the participating websites, you’re also logged into all the others. So for example, if both and are participating websites .. and I, the evil hacker dood, am able to steal your authentication credentials for your Myspace account (either by an XSS flaw or hacking it’s database) … that means i can also now log in as you at and finally prove to the world that UFOs really do exist, and the US gov’t has been trading horse-porn for ultRa secret alien weapons.

    Rather than having only one point to secure, it causes the exact opposite. If 50 websites participate that you have accounts for, all the evil hacker dood has to do is find a flaw in one of those 50 sites, and 50 doors unlock instead of one..

    SPoE = securest solution in the real world
    SSO = least secure solution in the digital world


  6. RSnake Says:

    Exactly, Maluc. Omer, I see what you’re saying, but the semantics are important here. Single Sign-On means just that. I click one place and I am signed in at lots of locations (all applications trust whatever operation just happened and validate my session). That would be fine except for cross site request forgeries. Most of the time I only want to be authenticated into the thing I am typing my password into, but now I am authenticated in lots of places. That opens the door for CSRF as an authenticated user. Yes, it’s a trust model, but it’s a trust model that can only exist when Single Sign-On is initiated - to me they are interconnected.

  7. Brian Says:

    The problem with calling SSO the “least secure solution in the digital world” is that
    a) for many businesses, not doing SSO is like burning piles of money.
    b) not all SSO solutions are created equal.

    A conversation about SSO that begins and ends with “you shouldn’t do SSO because it is insecure” is basically silly. You have to consider the risks AND the rewards. Anything else is pointless security navel-gazing. Richard Feynman’s quote about the difference between math and physics comes to mind.

    OK, that rant off my chest, here’s a few general comments on risks and rewards.

    RSnake’s point about SSO increasing the risk due to CSRF is right on. I don’t know of any SSO solution that doesn’t increase that risk (if anybody does know of one, I’d love to hear about it.) However, it needs to be pointed out that a CSRF vulnerability in an application is a risk whether or not there is SSO. And you can mitigate the risk of CSRF while still keeping SSO.

    Many SSO systems increase the damage done by XSS attacks. For example, let’s say you use a domain cookie for SSO from to Now, an XSS vulnerability in either site lets you in to both sites. The more sites you have, the more likely your whole authentication system is compromised by a vulnerability in one of the sites.

    Other SSO systems have been specifically designed to reduce the damage done by XSS attacks. For example, LiveJournal redid their authentication system so that an XSS attack embedded in one person’s page will not compromise other people’s pages.

    Another frequent way that SSO reduces security is via poorly designed SSO tokens. Is the token properly encrypted and signed? Does the token expire? Is the token targeted at a specific site, or can it be used anywhere? Is the token single-use, or can it be used multiple times? Is a record kept of when the SSO token is issued, and when it is used? Is there a way to automate examination of those records for suspicious patterns?

    Moving on to some rewards, security and otherwise…

    If you create an SPoE to your authentication system, you reduce your risk of attacks on user’s passwords via things like SQL injection. Which would you rather audit, 100 web sites written by different people in different programming frameworks, all with access to your password database, or 1 web site with access to the password database and 99 using an SSO system?

    SSO reduces your costs due to password resets because people have fewer passwords to remember. You know how automated password resets decrease security? There’s a trade-off here. If you reduce the number of calls to the help desk because of a forgotten password, you might not have to introduce that automated password reset system in the first place. You trade off the risk of someone attacking your password reset system for the risk of someone attacking your SSO system.

  8. Omer Taran Says:

    here’s the deal. If you link the pentagon and mysapce together you’ve got a problem and it has nothing to do with SSO. I’m talking about practical security (that is, real life) wheras you’re talking narrow theoretical issues.

    SSO is about closing multiple security holes and creating a new one. a recognised one. You NEVER link a system to a SSO solution if you do not make sure all systems are at the same security level. we’ve been through “multiple password is more secure”. we know it doesn’t work.

  9. Paranoid 101 Says:

    Putting a guard at the building entrance is good (sso), but some folks like to sneak into the building from the back door.

    So put a guard on the apartment door . . . but some folks might come in through the appartment window.

    so add a guard on the keg . . . that’s where everybody is headed.

    Problem is . . . sso tends to change the focus and leaves the keg open.