“Log in with” Misconfigurations, Convenience, and a Recommendation to Tier Your Accounts

I’ve been following a recent series of excellent blog posts from Salt Security, explaining how on several websites, an OAuth misconfiguration (technically a mistaken validation flow) exposed those websites to exploitation by malicious actors. (See https://salt.security/blog/oh-auth-abusing-oauth-to-take-over-millions-of-accounts )

Specifically, this is a way for these malicious actors to exploit the convenient “Log in with” capability, which many sites use to allow visitors to authenticate with their accounts from major platforms-for example, Google, Apple. Facebook. Microsoft. These platforms act as the de facto end user identity providers of record for many of us. This is very convenient, and helps us all to stem some of the proliferation of accounts across the myriad of sites we use.

From an enterprise security perspective, asking (or requiring) our developers to use an open standard such as OAuth, for user identity and authentication is a big win. It eliminates a great deal of complexity for our developers, and greatly improves the end user experience. However, it’s important to make sure we (and our developers) fully understand how to use these standards, and the risks associated with a misconfiguration.

In the case discovered by Salt, a malicious actor operating a site could reuse a user’s OAuth token on another site, to login as that user. For example, suppose a malicious actor operates a site such as “SeeYourselfAsABabyAlien.com”, and gets people to login with their primary online accounts in order to generate and share humorous photos of themselves morphed into (for example) Grogu. This actor promotes this site in order to obtain legitimate OAuth access tokens for their users. If we’re not properly validating the token, like in the sites that Salt discovered, the malicious actor could reuse those tokens to access user accounts on our platform. 

From the end user perspective, while this implementation flaw doesn’t put your main account at risk, it does put your account in those other platforms at risk of takeover. So what should we do? Does this mean that “Log in with” should be skipped in favor of creating our 153rd standalone account? Possibly- but only if you don’t reuse a password from other sites. Remember, we can’t fully trust the operator of SeeYourselfAsABabyAlien.com, no matter how much we love Grogu.

A better approach is to create a tiered set of accounts, and group things by their risk level. For example, I have deliberately created three Google accounts, one as my primary personal account, one as a professional/personal account, and one as a “junk” account.

This way, I can use the junk account to obtain the convenience of “log in with” for sites such as the photo generation site above, and use my other accounts for sites that have financial or professional risk associated with them. For my most important accounts, such as bank accounts, I don’t use cross-site logins at all. Do keep in mind that some of the major consumer identity platforms make it difficult to have multiple accounts, so they can’t be easily used with this technique. 

Using multiple email accounts may seem to be an inconvenience, but it really isn’t. I get so much promotional email from  necessary-but-not-that-important accounts that it’s very much worth it to have, and regularly utilize, my junk email account. 

Overall, the team at Salt continues to do excellent work–thank you. This example highlights the need for us, as security professionals, to ensure that even when our development teams are using our recommended approaches, we validate the implementation. We’re building and operating complex, interdependent systems, and we need to be thorough. Our customers are depending on us.