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.