Over the years many of us have succumbed to a very serious condition, sign-on fatigue. Being required to continually supply a username and a password whenever you wish to start using a site or to log back into it. We all knew the passwords should differ between sites, however, when so many are needed this becomes tiresome at best or even impracticable. When we hit this wall, we tend to find shortcuts, in this case reusing passwords.
Over the years a few of the larger organizations recognized this and offered their own solution. Organizations such as Google, Microsoft, Facebook and Twitter (among others) started offering a single sign-on service.
Fantastic! we thought, now we only need a single username and password to log into any site (well for those that supported single sign-on that is). Some sites actually support multiple, Medium, in fact, the site you are on supports several (at the time of writing, Twitter, Facebook and Google) as well as the traditional username and password.
Over the years, however, we have discovered that user experience was not the only motive that these service providers had. By offering such a service, they could track which sites you visit and get an understanding of how often you visit the site. By doing this they could build a picture of who you are, what you like and dislike. This data can then be used to give targeted ads. There is, of course, another benefit, by using the service you build a reliance on them, thus making it extremely more difficult to stop using or even deleting your account.
Upon checking my personal Facebook single sign-on’s, I see that I am actually quite a light user. At the moment I have:
- 9 Active (used recently)
- 12 Expired (not used for a while, some recently expired, some a long time ago)
- 157 Removed (I have actively disabled these within Facebook)
Wider Security Implications
Unfortunately, this is not the last of our problems. After a quick glance at the services that I have used Facebook as the single sign on provider, it is actually quite frightening. The services include:
- A bank
- A credit card provider
- Music streaming services
- Crowdfunding services
- General websites
- A security application
Yes, you read that correctly, a bank and a credit card. These are obviously directly related to my financial health, however so are some of the crowdfunding sites and general websites. And my access to these relies on a third party login provider? I am not sure about you, however, I found this quite eye-opening and makes me wonder what I was thinking.
But it is O.K., No-one else has access to these, right?
You would certainly hope so, however, in late 2018 Facebook discovered that they had a spike in traffic utilizing a particular feature. This sparked an investigation as to what the cause was. Facebook discovered that a bug in the “View As” feature, a feature that allows you to see what another user may see when viewing your account, had a bug within the code. The bug actually enabled someone to gain access to an account as if it were their own. This bug was actively being leveraged by “bad actors” to access user accounts.
How does this relate to single sign-on?
If your account is compromised in such a way an attacker has the ability to ascertain what services you use Facebook as a single sign-on provider for (or whichever single sign-on has been compromised). Armed with this knowledge, and having access to your account, they can then access those services trivially, in fact, if you are already logged in, handily the single sign-on recognizes this and grants access with no challenge.
It would be easy to dismiss this as purely a problem with Facebook, unfortunately, this is not the case. In 2018 Google admitted issues in the logic for Google+ allowing developers to access personal information (this bug was present for around 3 years). Although this did not give access to the full account, it demonstrates that other large organizations offering similar services are not immune to such errors.
So Where Do We Go From Here
The problem that caused the need for single sign-on is still present, so far we do not have widespread adoption of potential password replacements. Solutions such as Fido2 and U2F look promising, however, at present, it appears browsers and their creators are more concerned with using the technology to increase their own market share than to aid in the mass adoption of the protocols.
Until such solutions are implemented fully and become widespread we still have the necessity of Passwords or continuing the use of single sign-on.
A popular method at present to live with the growing number of passwords (and keeping them secure) is utilizing a password manager such as LastPass or 1Password. Although I am a proponent of using a password manager (despite my obvious usage of single sign-on) this method does still give me concern. We are still reliant on a single entity to manage our logins (or in this case login details) securely. Such services are not immune from attack, in 2015 LastPass announced they had been compromised, although in this instance the advice was that no data was compromised. Their security model helps reduce the risks regardless of data centre breaches, however, one thing that makes services so useful is their mobile apps and browser extensions, these act as another attack vector.
At present, our best options are using a single sign-on service or a password manager that we trust. Both options should leave you with an uneasy feeling trusting a 3rd party with the keys to your kingdom.
Moving forward our best hope is that browsers step up and start supporting protocols such as U2F and Fido2 fully. Until such time that a consistent experience using such protocols alludes us, widespread adoption will not occur, services will not spend the time, energy or funding in enabling such features.
For those wishing to identify the sites that they use Single Sign-on for, I have written several articles showing how to do just this:
Until then stay secure (at least try).