A Comprehensive Formal Security Analysis of OAuth 2.0 | Hacker News Reader

A Comprehensive Formal Security Analysis of OAuth 2.0

arxiv.org

(2016)

> When proving the security of OAuth in our model, we discovered four attacks which break the security of OAuth. The vulnerabilities can be exploited in practice and are present also in OpenID Connect.

> We reported all attacks to the OAuth and OpenID Connect working groups who confirmed the attacks. The OAuth working group invited us to present our findings to them and prepared a draft for an RFC that mitigates the IdP mix-up attack (using the fix described in Section 3.2) [24]. Fixes regarding the other attacks are currently under discussion. We also notified nytimes.com, Facebook, and the developers of mod_auth_openidc and pyoidc.

The burning question is what has happened since. I couldn't find an RFC or errata about the other issues.

(Aside from formal analyses being cool research. :)

[24] https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mix-u...

Have you seen this? https://oauth.net/2.1/

Yes, I skimmed through that page and got no answer, perhaps because I don't know enough. Did you find answers there?

Kind of tangential, but one thing I realized recently I didn't get about oauth2 (or openid), social logins for that matter: when you click on the login button, you're sent to whatever site the site you're logging in to wants to send you. It could be a fishing page or whatever. Is that not a significant issue?

I've never seen any warnings about this - I feel like generally it's touted as a better (practical, secure) alternative than having your own per-site email address and password, and most identity providers are careful to say "are you sure this is the site you want to log into" (mostly because people are abusing oauth2 for logins), but nobody says "hey, triple check before clicking an off-site login link!"

I feel like there needs to be browser-side integration that keeps track of which identity providers you have, and which ones you've previously used on which sites. Somehow facebook pushed passkeys through, so it's not like browser-site cooperation can't happen in the login space.

IIRC there were some oauth2 alternatives years back but I don't think they went anywhere. It'd be nice to get rid of all the cruft in the standard about http logins, maybe support flows that don't rely so heavily on DNS, etc etc too.

> Is that not a significant issue?

No more an issue than normal.

I don’t see how oauth makes it easier to phish.

The attacker would need to have a fake or compromised site send the victim to another fake site.

Without oauth the user would type in their more limited per-site credentials, not their google creds or whatever.

Splitting hairs if people reuse passwords, but I feel like "don't reuse passwords" is easier to digest for the layman than "check the ssl cert".

any phishing email could just directly link to a fake Google login form. Oauth just adds extra steps for the attacker.

> when you click on the login button, you're sent to whatever site the site you're logging in to wants to send you. It could be a fishing page or whatever. Is that not a significant issue?

You can (and should) restrict which URIs are allowed for the callback after authentication.

Social authentication providers typically mandate this be a specific domain or list of domains, which essentially creates an explicit allowlist.

However, of course, nothing stops a threat actor from abusing social authentication anyway. They can just create the integration client on the social platform’s developer console and use the system as intended. That is true of any federated and open-for-business authentication provider. I don’t say that in the spirit of criticism of course.

> I feel like there needs to be browser-side integration that keeps track of which identity providers you have, and which ones you've previously used on which sites. Somehow facebook pushed passkeys through, so it's not like browser-site cooperation can't happen in the login space.

1Password had made a big deal about exactly that feature as being a foundation for the “1Password Future”, and then abruptly stopped talking about it. It exists in the client apps but it’s a bit clunky and they seem to have stopped improving it.

If you’re using Apple ecosystem devices, there is a default-enabled setting to silently setup passkeys with sites that support doing that. You can disable it in the settings of the Passwords app. It seems to be a per-device setting, which is ridiculous because the passkeys get synced regardless, if iCloud Keychain is enabled.

Callback restrictions only happen if the user is sent to a valid IDP. That's a protection later in the process, for a different target (getting a valid user token), not what I'm talking about here (stealing the user's IDP credentials).

The alternative would be to not use a third party IdP, but the issue of stolen end user credentials is still present.

> Is that not a significant issue?

One would of course check the certificate to see that you're actually on the correct login page before entering credentials...

A more user-friendly approach could be if one could register a keyword with your IdP, or even a reverse TOTP for added protection. The IdP login screen would then contain the keyword/reverse-TOTP, and you could verify it before entering your credentials (using your authenticator app to validate the reverse-TOTP).

That said, I do like your suggestion about the browser recalling which IdP you've used for a given site. But it wouldn't be bullet proof as people sign in from fresh browser instances all the time, be it an internet cafe or just a new laptop.

Right, good point. Well, if they were using a cloud password manager (apple passwords, 1password, etc) presumably that wouldn't be an issue.

Of course, not getting phished the first time you visit a site would still be an issue.

Reply on news.ycombinator.com