A rash of rogue food orders with the company Deliveroo allowed hungry hackers to go on a booze and food binge in 2016—they logged in to customers’ accounts, changed delivery addresses, and ordered whatever they pleased. The mistake that Deliveroo made was not requiring the credit card security code allowing hackers to keep using the credit card on file.
Interestingly, Deliveroo did not have a data breach. No credit cards were stolen, no passwords exposed by the company, no outdated servers compromised. How did the hackers get into the accounts if Deliveroo didn’t have a breach?
Password reuse is so prevalent that hackers took known email addresses and passwords from other breaches and simply used them to sign in to Deliveroo accounts. Everyone has so many accounts now that it’s all but impossible to maintain a unique password without tools and help.
“Sign in with Facebook”
One of the tools available to reduce the number of passwords that users need to remember is Single Sign-On (SSO). The ubiquitous “Sign in with Facebook” and “Sign in with Google” are the prime SSO examples. They offer users a convenient way to log into many sites without the need to remember multiple passwords. In identity parlance, Facebook, Google, and others act as an “External Identity Provider.” A corporate world equivalent, for example, is Azure Active Directory, which is a topic for a different day.
User Perspective
What happens when a user clicks “Sign in with Facebook” in a web application? The application redirects the user to the Facebook login page. If the user isn’t already logged in, they provide their Facebook credentials. This part is key, the web application at no point sees the user’s credentials. The credentials are between Facebook and the user, no one else. After the user proves who they are to Facebook, the web application receives back several pieces of information. This information must be pre-approved by the user and may consist of the following:
- Unique User ID
- E-mail address
- Name
- Phone Number
- Address
- Other parts of the user's profile (Facebook, Twitter, etc)
Another benefit is that social SSO provides one of the fastest registration processes. If the user is already signed into Facebook, it can simply be a click of a button.
Web Application Perspective
Under the hood, Facebook maintains a unique ID for every user. The application trusts Facebook and receives this ID, instead of accepting a username and password. That’s it. At its core, that is SSO. That ID is everything the application needs to look up and use the information that it has on the user.
Facebook does not receive information from the web application through SSO. Facebook acting as the identity provider serves a very narrow purpose, authentication.
- Prove who the user is. The application doesn’t need to know if the user authenticated with a password, fingerprints, or a DNA sample.
- Provide a unique identifier of the user to the application.
The consumer-facing social identity model is that authorization information stays with the app and authentication information stays with the external identity provider:
- Centralized authentication and user identity.
- Distributed permissions and authorization to web applications.
Email Passwords
Arguably, the biggest problem with identity management today is the reuse of passwords across websites. In particular, the reuse of email account passwords. If an email password is reused on a website that is breached, the hacker has enough information to log in to nearly every single account the user has. All the hacker has to do is reset the password on any sites that are registered with that email address. Make sure the password for your email address is unique, along with any service you use for SSO.
A common follow-up question is “I see all these breaches in the news, how many affect me?” You can check if you have an account compromised in a data breach. A great tool for this is Troy Hunt’s https://haveibeenpwned.com/. Troy aggregates data breach databases into a single lookup. All you have to do is enter an email address, and the site returns a list of breaches that contain that account. The site even provides the option to get notifications if your email address shows up in a new data breach. A user finding their account in a breach provides concrete personal examples, which is the best way to encourage people to maintain good password hygiene.
Risks
Single Sign-On is not without its risks. When analyzing security choices, it helps to make a relative comparison and make a judgment as to which is more secure. For example, does a newly published game by a startup have better password security than Facebook? Likely not. In that case, SSO makes a lot of sense.
Generally speaking, companies like Google, Microsoft, and Facebook follow standards and have teams of people ensuring that they have secure password storage, including multi-factor authentication. As a result, SSO through social platforms is a viable option for many applications. Unfortunately, the striking example of the 3 billion emails hacked at Yahoo! reminds us that there is no completely secure system (https://thehackernews.com/2017/10/yahoo-email-hacked.html).
Recently, Facebook had a vulnerability exposed that allowed a potential hacker to retrieve a user’s SSO token (https://thehackernews.com/2018/09/facebook-account-hack.html). This would allow the perpetrator to use SSO as if they were signed into Facebook as another user.
In addition, SSO providers do not have an uptime SLA. If the SSO provider has an outage, a user may still be able to log in if the website offers a local account.
As a result of these risks, in many corporate and B2B scenarios, SSO through social platforms is not recommended.
Summary
Single Sign-On is a great option to reduce password reuse and accelerate user registration. As a user, it’s critical to make sure SSO account passwords are unique. Application owners can worry less about the latest authentication vulnerabilities and don’t have to figure out how to store passwords securely.