3 ms·

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,

by 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.
- rendaw 2y ago
  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).
  - TheNewsIsHere 2y ago
    The alternative would be to not use a third party IdP, but the issue of stolen end user credentials is still present.
magicalhippo 2y ago
> 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.
- rendaw 2y ago
  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.

by rendaw 2y ago

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.

rendaw 2y ago
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).
- TheNewsIsHere 2y ago
  The alternative would be to not use a third party IdP, but the issue of stolen end user credentials is still present.

magicalhippo 2y ago

> 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.

rendaw 2y ago
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.