By Keith Casey, Okta API Problem Solver

Another day, another breach headline. What’s unique about the latest Facebook breach is that it’s the source of truth for many other companies and applications who use social platforms for authentication. A vulnerability in a social authentication service has far-reaching effects across thousands of apps and millions of users. But while social authentication or identity federation look like the major culprits here, at the end of the day, they just allowed the issue to spread, and there are steps that organizations can take to mitigate these challenges.

1. Require MFA at the Identity Provider Level. First, at a basic level, requiring a second factor of authentication should be a standard practice for your Identity Provider (IDP), be it an enterprise IDP like Okta or a social network such as Facebook. Using an IDP makes authentication simpler and more secure for both the end user and the organization: with social authentication, when a consumer visits a new website, instead of creating a new account, they can “Log in with X” and use Facebook, Google or LinkedIn. After authenticating on that site, the user is redirected back to their desired site and their profile is created. Some websites will go a step further and use their profile information, such an email address, to look up and combine this new account with a previous profile. Loyalty programs do it for marketing purposes, and banks, healthcare, and other may do it for convenience and flexibility for ever-connected consumers.

Because your IDP is the source of truth trusted by all other systems it is therefore the single most important place to protect. Let’s face it: organizations need to be right 100% of the time, while attackers only have to be right once. With 80% of breaches today caused by poor or compromised credentials, adding multi-factor authentication (MFA) is a critical component of modern security hygiene for every app or website today – helping to prevent a poor password or credential-focused attack from becoming the weak link that allows an attacker into your ecosystem.

2.  and Also Before Linking Accounts. Next, require MFA before you link existing and social accounts. Take an example of what this latest exploit could look like when it comes to using social authentication with your bank’s online portal: if I have your Facebook/Google/etc. account and I go to a banking app and choose “Log in with X,” I bounce to the social site, come back to the bank as “you” for all intents and purposes. If your bank and social account are already linked, I’m you. If your accounts aren’t linked, your bank may be “helpful” and offer to link it for me based on email address. Once again, I’m you.

That’s not to say that federated identity management should be abandoned as a result: the core values of social authentication still hold true. It’s simpler for both the organization and the end user, and ultimately can play a role in helping to minimize the potential attack surface of users by limiting the number of accounts they’re managing credentials. But whether you are a bank, hotel chain, or a similar consumer-facing business, you should use previously provided information such as email or phone number to confirm this linking is the actual user. At minimum, you could notify the user of the newly linked account to give them the opportunity to mitigate the attack in progress. Alternatively, if your Identity Provider supports step up multi-factor policies, you can designate certain applications as high security/risk and require MFA for them regardless of how the user authenticates. Many Okta customers do this internally for payroll systems and externally for changing travel reservations.

3. Zero Trust for Social Auth. Treat social authentication as a minimally trusted or even untrusted within your ecosystem. Between quizzes, silly apps, exploits, and the like, most people don’t treat security seriously in social media. When the worst consequence is an inappropriate post, that may be okay. When that social network is a major basis for identity and single sign-on for the Internet, the consequences could be catastrophic. This isn’t specific to any particular social network, it’s just not within the realm of how the public considers security and modern digital identities. Therefore, as app creators and users of social authentication, we need to act to mitigate attacks.

In the near term, any transaction such as booking a hotel room, transferring money, or resetting a password must require a reauthentication or additional factor to confirm the user’s approval. While this feels inconvenient in the short term, it can mitigate fraud, support issues, and corporate brand damage.

4. The Real Problem: Don’t Allow Impersonation. Finally, the core of this entire issue is impersonation, or the ability to look at a system as someone else. The initial scenario for Facebook was, “How does this person see my profile?” – but instead of acting like that person, Facebook allowed you to become that person by generating an access token for that user. It’s the equivalent of going to a hotel to meet your friend for dinner, and the front desk giving you their room key. Usually companies want user impersonation so their support team can see issues first hand or test out features. Unfortunately, when we have someone that lets us look and act like someone else, the boundaries become blurred. Can the impersonator add things to your shopping cart? Can they check out? If something goes wrong, can your logging distinguish the two?

Impersonation seems beneficial until you consider the consequences, implications, and every use case that might occur. When you combine the two, you have a potentially vulnerable system that could compromise downstream systems and impact every user and potentially every use case. I say “potentially” because it’s now impossible to separate fact from fiction. So how to mitigate this issue? This one is simple: don’t allow impersonation. The advantages are minor and the risks are catastrophic.

The benefits of social authentication are clear: simple, secure authentication for both the user and the app. By taking the simple steps above, organizations can take advantage of social authentication while also mitigating potential threats to their users.

Keith Casey works on Identity and Authentication APIs at Okta. His goal is to get great tools and technologies into smart people’s hands to do amazing things