There are some interesting tidbits coming out about the Chinese hack of Google. Apparently the source code to Google’s SSO technology was a target (although this is misstated in the headline as a “password system”). It’s unknown at this point what source code (if any) was taken, but this highlights the nightmare scenario of the SSO world.
If a vulnerability is found in your token generation code such that someone can spoof a token, then your SSO system and every system connected to it is compromised.
Of course just having the source code is not in itself a problem. Typically there is a private key that is used to encrypt or sign the token. But protecting that private key is the issue and that is where the source code is key. If you think your key has been compromised you can replace it. But the code that authenticates the user and generates the token needs to get the private key to do the encryption (or signing (or both)). If the secret algorithm to access that key is compromised, then the attacker can then attempt to penetrate the system where that key lives and get the key. With the key and token generating code in hand the attacker can then access any SSO protected system.
And here is an ugly secret. If the SSO technology is public key encryption, they key on needs to exist where the token is initially generated. If it’s based on symmetric key encryption then the key has to exist on every server in the SSO environment.
So just use public key encryption, that solves the problem right? Not so fast. One critical aspect of SSO is inactive session timeout. That requires the token to be “refreshed” when used so that it expired based on inactivity. Refreshing the token at every server in the SSO system (every PEP if you will) requires either that server to have the key, or it make a remote calls to a common authentication service to refresh the token.
There are pluses and minuses to both approaches. One puts the keys to the kingdom in more locations but the other adds overhead to the token refresh. When security and performance collide, who do you think usually wins?
These kinds of trade offs are what make SSO so interesting to me.
Note that I am not talking about federated SSO (SAML or openid) or intranet SSO (Kerberos) as they present a different set of challenges.
Jeff Atwood has this post about the dangers of copying code from the internet and writing your own crypto routines. He includes this very funny play from Thomas Ptacek about writing crypto which also touches on one of my favorite topics, web SSO.
I do question Jeff’s comment about “thoroughly reviewing code”. These kinds of issues are very seldom found in code reviews from what I have seen in 20 years of doing them. It is very difficult to review someone else’s code and catch all the subtle land mines that might exist. You get lucky once in a while and find something, but all that does is reinforce a false sense of confidence that your review process is preventing these sorts of errors.
That’s not to say you shouldn’t do code reviews, but be realistic about it. Code reviews are useful to find obvious stuff and to share knowledge about the code across team members, but you aren’t going to find the subtle errors.
One theme I have harped over the last year of so is that it means little for the big content providers to become OpenID providers if they don’t also become relying parties. You can’t build a highway with nothing but on ramps.
So far the vast majority of OpenID announcements by the big players have been to be yet another OP, or just signing up for the OpenID Foundation. It looks like the game is finally changing. Apparently Facebook is getting ready to become an OpenID Relying Party. From Inside Facebook:
Less than three months after joining the OpenID Foundation’s board as a sustaining corporate member (i.e. putting its weight and financial support behind OpenID), Facebook has just announced at the “technology tasting” event this afternoon at its Palo Alto headquarters that users will soon be able to log in to Facebook with their OpenID.
This could be huge for OpenID adoption, if it really happens.
Google has apparently had a serious flaw in its implementation of “SAML” (quotes intentional) that has just been closed. Kim Cameron takes Google to the woodshed:
This is all pretty depressing but it gets worse. At some point, Google decided to offer SSO to third party sites. But according to the researchers, at this point, the scope still was not being verified. Of course the conclusion is that any service provider who subscribed to this SSO service – and any wayward employee who could get at the tokens – could impersonate any user of the third party service and access their accounts anywhere within the Google ecosystem.
My friends at Google aren’t going to want to be lectured about security and privacy issues – especially by someone from Microsoft. And I want to help, not hinder.
But let’s face it. As an industry we shouldn’t be making the kinds of mistakes we made 15 or 20 years ago. There must be better processes in place. I hope we’ll get to the point where we are all using vetted software frameworks so this kind of do-it-yourself brain surgery doesn’t happen.
Let’s work together to build our systems to protect them from inside jobs. If we all had this as a primary goal, the Google SSO fiasco could not have happened. And as I’ll make clear in an upcoming post, I’m feeling very strongly about this particular issue.
Jackson Shaw poses this interesting question:
Could Google’s predilection for those who have just emerged from the fountain of youth have contributed to this SSO “disaster”? Obviously, I don’t know if it is a contributing factor or not but I do wonder.
I wonder too. The irony is that there are any number of SAML experts that Google could have hired to help them and perhaps have avoided this embarrassment.
However I would like to take exception with Connor Cahill’s suggestion that all would be well if Google had just used pseudonymous IDs (such as SAML 2.0 Persistent IDs):
While I agree totally that the intended recipient should have been identified within an <AudienceRestriction> in the SAML assertion (how SAML shows the intended scope of the assertion) the problem would have been moot if Google used good pseudonymous identifiers for its users.
This is a very dangerous suggest as it implies that SAML is not secure enough without pseudonymous identifiers, the use of which makes SAML deployment a lot more complicated. Pseudonymous IDs are for privacy not security. If your system requires them to be secure, you have done something wrong. Period.
Jakob Nielson declares Portal SSO to be the Loch Ness Monster of Portal Usability (hat tip to Vikram Kumar):
Single sign-on is the Loch Ness monster of the intranet world: People hear about it and even believe it exists, but they’ve yet to see it for real.
In our initial research 5 years ago, it was already clear that single sign-on could dramatically improve user productivity and satisfaction, as well as immensely reduce support costs. (A huge proportion of help desk calls relate to password problems.) At the time, single sign-on was more of a hope than a practical possibility.
Our second round of research confirmed single sign-on’s potential – and its elusiveness.
True single sign-on (SSO) was and is extraordinarily rare, as our third round of research shows. We can only conclude that it’s very difficult to achieve, despite its promise. That said, we’re starting to see an interesting, pragmatic approach to what Kaiser Permanente calls “reduced sign-on.” Work as hard as you can to reduce the number of authentication requests users encounter each day, even if you can’t get it down to 1. You can also reduce frustration by informing users about the impending login request before they click the link that activates the demand.
And this is a real shame. I saw many successful Portal SSO projects at OpenNetwork, but to the vast majority of enterprises it just isn’t a high priority. Too many don’t see the ROI.