3 ms·

A Comprehensive Formal Security Analysis of OAuth 2.0

flowerthoughts 2y ago
(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-up-mitigation-01 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mix-u...
- ivan_gammel 2y ago
  Have you seen this? https://oauth.net/2.1/ https://oauth.net/2.1/
  - flowerthoughts 2y ago
    Yes, I skimmed through that page and got no answer, perhaps because I don't know enough. Did you find answers there?
rendaw 2y ago
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.
- dartos 2y ago
  > 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.
  - rendaw 2y ago
    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".
    - dartos 2y ago
      any phishing email could just directly link to a fake Google login form. Oauth just adds extra steps for the attacker.
- TheNewsIsHere 2y ago
  > 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.

(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-up-mitigation-01 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mix-u...

ivan_gammel 2y ago
Have you seen this? https://oauth.net/2.1/ https://oauth.net/2.1/
- flowerthoughts 2y ago
  Yes, I skimmed through that page and got no answer, perhaps because I don't know enough. Did you find answers there?

rendaw 2y ago

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.

dartos 2y ago
> 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.
- rendaw 2y ago
  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".
  - dartos 2y ago
    any phishing email could just directly link to a fake Google login form. Oauth just adds extra steps for the attacker.
TheNewsIsHere 2y ago
> 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.