starseerdrgn: a white dragon with azure crystal horns and snout scales (Default)
starseerdrgn ([personal profile] starseerdrgn) wrote2016-03-28 07:13 pm

Single Points of Failure

Every time I turn around, I see someone in the tech industry say that developers "shouldn't even try to handle passwords themselves", and to rely on things like Google SSO, Facebook Connect, and Login with Twitter. Sadly, that's insecure as well. In fact, they're as bad as using nothing but email to authenticate someone.

The problem with these single sign-on (SSO) solutions is that they're a single point of failure. In most of these cases, all you need is access to someone's Twitter, Facebook, or Google account, and you'll be able to log in and cause havoc in their name. That's it, game over, just as if you'd gained access to their email—and in the case of Google, you'd be doing that and more.

Even Mozilla has been trying to do it, first with Persona (which you could potentially roll yourself), and now with Firefox Accounts (which is centralized, from what I can tell). Apple may become the next to implement something like this with AppleID.

The problem is this: the easier it is to secure something, the less secure it tends to be—something which I've previously seen referred to as the Convience-Security Spectrum. By making it dead-simple for a majority of users, the service itself becomes a security risk. In the case of a single sign-on provider, it becomes a target, providing a single point of entry for a truly malicious individual or group to take over someone's entire internet life.

The issue lies in the fact that there's no second level of authentication. Even with basic multi-factor authentication (MFA), you have a second form of proof coming from another location, such as your phone or a security token. If your product is relying on a SSO alone, even if they have multi-factor authentication, you're relying on a single factor from your own standpoint: the SSO solution. You're relying on security that you can't control, hoping that their security is good enough to keep your users safe.

OpenID had this problem as well, as the moment someone figures out your OpenID URL and password, they have access to anything which allows OpenID logins, and any accounts you may have connected to it. However, with OpenID, you at least have the ability to take control of the security on the backend, as you can implement it yourself.

This level of centralization is inherently insecure, because it's a single point of failure. That's why decentralization is so important, as it allows for multiple points of failure that can protect the user from absolute catastrophe.

Today, if someone were to hack a common user's Google account, there's a very good chance that they'd be able to effectively take over their entire life. Many people rely so heavily on Gmail, that their other accounts will very likely have their password reset email set to it, and that's assuming the account isn't set up with "Sign-in With Google" (Google SSO). If its the latter, they don't even need to send a password reset to get into the account. They can just log in.


I just don't understand what the draw for uncontrolled single sign-on is all about.

I can understand making things easier for the common users. Security is difficult, and not many can really understand the need for strong passwords, much less the need for different passwords across multiple websites.

I try not to use single sign-on when possible, but in some cases, it's just not an option. Originally, Medium would only accept Twitter or Facebook sign-ons, and I tired it for a bit, but gave up on the platform. Likewise with inter-connected services like Google and Microsoft's various services.

I just really hope this doesn't become a continually growing issue. I don't want to have all of my accounts under a single password.