US security researchers have unearthed flaws in the single sign-on (SSO) services operated by a number of portals, including Google and PayPal. Idiosyncratic methods of integrating the APIs, SDKs and sample code supplied by identity providers are creating exploitable security shortcomings, according to a study by two researchers …
Link just redirects to Bing.
Sign of the apocalypse?
If we need to rely on MS for SSO help then all is lost...
Re: Sign of the apocalypse?
Actually SSO is one thing that MS are extremely good at. I've worked at several FTSE 100 companies who have all their signon handled by AD from mainframe to desktop.
Not my Farmville ID!!!!!
This is just one big security nightmare waiting to happen (If it hasn't already).
Hmm, all these so-called experts putting forward ideas of using a Farcebook login for SSO purposes. Not that they have ever been faked...
What is the bookish farce you speak of?
Microsoft helped with this research, but no mention of testing Microsoft's LiveID?
Is that because Microsoft didn't want their SSO system criticized, or because nobody's using it?
Has everyone forgotton one of the main rules for security - "Dont use the same password everywhere". Single sign on is just nother name for that !
It's a bad idea, bad !
Yeah but No but Yeah but
Single sign-on is not quite the same as using the same password across disparate systems. Single sign-on uses one password, but that password should only ever be given to one system: the trust authority. That authority then generates tokens which are specific to the requestor but do not contain the password.
So defeating single sign-on requires defeating a specific target, but one which has been (hopefully) better secured.
Defeating the multiple-system-one-password concept, on the other hand, requires only defeating the weakest system, whichever it may be.
It's like the difference between divulging your entire war strategy to all of your troops, or only with a general and trusting him to lead the troops as necessary.
Or like a celebrity caught in a crowd of fans.
SSO = Single Point of Failure
Always has been. Always will be. That's why our phone numbers are not used for bank accounts.
Our phone numbers aren't used for bank accounts?
They didn't exist when banks started, then they weren't for individual use, now we have many and change them. They also aren't checksumed and don't point to a specific bank (a la sort code).
SSO may be considered to be a single point of failure, but it's also a single bastion to be defeated, rather than a distribution of multiple systems. None SSO, encourages people to write down - or otherwise record - their logon IDs.
I only see OpenID providers. How about the SAML 2.0? OpenAM/OpenSSO/OID/ADFS2.0?
Janrain takes protecting the security and integrity of our solutions and customer implementations very seriously. We have a long record of contributing to and following industry best practices and standards, particularly in the field of identity and authentication. Last year we were informed by the researchers of their discovery, which in itself is a textbook example of how such flaws should be identified and resolved. Of the eight identified logic flaws, only two applied to the Janrain solution and both issues were fixed immediately and prior to the flaws being made public. At that time there were no known examples of attacks using the techniques described by the researchers.
Predictable press release is predictable.
Addressing vulnerabilities found by outside researchers is good. Finding those vulnerabilities in-house before going into production would be better.
I recognize that Janrain's SSO mechanism is unavoidably complex (because it wraps disparate third-party SSOs into a common framework). And the exploits against Janrain detailed in the paper are not trivial and require some additional effort (for example, if Bob wants to impersonate Alice on a site foo.com that's protected by Janrain-wrapped OpenID, Bob has to get Alice to visit his own site first, so some social engineering, DNS poisoning, or other preliminary attack is necessary).
But that said, the first successful attack against Janrain relies on letting the attacker bind a Janrain session ID to a different RP. That's a hole that I believe someone at Janrain should have caught.
The other exploit is largely due to a weakness in the Facebook SSO system that Janrain wraps. As I understand the description in the paper, this really isn't Janrain's fault; the Facebook scheme relies on user agents (browsers) providing tighter restrictions on cross-subdomain cookie access than they actually provide.
Incidentally, Russell says above that both vulnerabilities were "fixed immediately", but the paper says that the fix for the Facebook issue caused compatibility problems and had to be rolled back. It's possible that Janrain has found another fix for that one (working around the flaw in the Facebook scheme itself) that's compatible with existing sites, but if the authors are correct, there was at least some delay.