Template:SWN67NewsJasonWood

From Security Weekly Wiki
Jump to navigationJump to search

Articles

Think Twice Before Using Facebook, Google, or Apple to Sign In Everywhere

I ran into this article on Wired today and while there was nothing wildly new in it, it turned into a pretty good exercise in reevaluating risks related to consumer Single Sign On (SSO). It starts off by pointing out the issue of dealing with passwords for the hundreds of sites we register for accounts on. We are supposed to create unique passwords that are long and complex; and we have to remember them. Companies like Google, FaceBook, and Apple created consumer SSO offerings so that sites could leverage their authentication platform for their site. The user doesn’t have to remember yet another password, the site doesn’t have to manage that account, and the SSO provider gets one more connection of dependence with the user. The Wired article asks (and provides their answer) to whether this is a good thing or not.

On the surface, it sounds like a good setup. For example, I trust Google’s authentication platform far more than I do some most other sites. I’ve tested and had to manage far too many applications that had really terrible authentication implementations. Some still make me shudder when I think of them. So as the user, I would benefit from Google’s better security and still get access to the site in question. There are some potential issues though.

First off, a large SSO implementation may make for a much more attractive target then a small e-commerce site. So it may get a lot more attention from some very clever attackers. If that SSO platform has a security flaw that exposes access tokens, the ability to log into the platform, or other related flaws, then it could unlock access to every site that users have set to use SSO. That would be a bad thing. In fact, the article cites a FB incident that exposed the SSO access for 50 million users. While they do state that FB reset the access tokens immediately, they didn’t seem to focus on the benefit of quick remediation. There’s no denying the reach of these issues is huge, but I also liked the quick response.

Second, they cite a legal disagreement between Epic Games and Apple over how in app purchases were handled. Apple revoked Epic’s access to the App Store and developer program. This had the impact of severing the SSO access and left Epic to scramble to find a way not cause users to lose access. Apple backed off of the SSO revocation and said they never intended to remove people’s ability to authenticate using SSO.

So is consumer SSO a bad thing or a good thing? The Wired authors have decided it’s a bad thing and that people should use password managers instead. My response was a bit more mixed, even though my preference remains to use password managers as well. I don’t know most of my passwords any more and haven’t for a long time. My password manager does though and I use that to generate very long and complex passwords that I have no hope in remembering. There’s been little appeal to me to use Google, FB, or whatever to log into a site.

However, there’s still some downsides to password managers. The biggest one is human nature. I’m willing to jump through an extra hoop to have my passwords on all my devices. Others aren’t so inclined and they want an easy way to do things. So either they will continue to reuse their passwords everywhere or they will use the easy button and login via Google or whatever. For these folks, using consumer SSO is a much better option. At least they get the benefit of the SSO’s security and ability to respond.

So is consumer SSO a bad thing or a good thing? After reading about it, I have to say the answer is… it depends. For my part, I don’t use it. I’ll use a password manager. For someone else, consumer SSO is a better option because they will just use the same password everywhere otherwise. And honestly, they will continue to do so since not every site supports Authenticate with Apple, or whatever. Take a read, do your own risk analysis, and see what you think.