1

The way I understand it, the whole concept of OAuth/SSO involves allowing a user the ability to have a central password they can use on a multitude of sites without compromising it because really they're signing into the service hosting their password.

Now, barring the use of two-factor authentication, as the average user does not use this feature, and using Google's SSO feature as an example, but realizing this applies to every similar service:

What stops me from writing an app that simply informs a user that we support sign in with Google and instead of redirecting them to the appropriate SSO page, I just provide a place for their Google username and password. I then emulate the user and authorize my app through the normal SSO process behind the scenes so nothing looks abnormal, and also store their Google username and password on my private server for malicious purpose later?

And if the answer is nothing would stop me, then why isn't 2 factor authentication mandatory on all these implementations?

  • 1
    what's preventing you? The threat of prison time. The ability for people to detect your phishing URL. 2FA doesn't really help here either except U2F – Neil McGuigan Jan 18 '17 at 1:46
  • It doesn't have to be a phishing url, that's my point. It can be a legitimate site that "incorectly" implements OAuth/SSO. – Andrew Hendrix Jan 18 '17 at 18:27
  • This is just a phishing attack, not inherently possible because of OAuth. You can lure the user to login to a false web site with all authentication methods - doesn't matter if it's pure user/pass login, OpenID, OAuth... doesn't matter. No online user/pass login mechanism protects you from the phishing attack you just described. – luben Mar 5 '17 at 13:02
4

Aside from the legal aspects alluded to by Neil McGuigan in the comments, it's also difficult to perfectly emulate, say, Google. For one thing, when I log in, Google shows my profile picture. Second, it asks me to perform my 2FA validation (I know, you're assuming most people don't use this, but for those who do, its absence is a red flag).

Reading your question closely, I just noticed this statement:

I then emulate the user and authorize my app through the normal SSO process behind the scenes so nothing looks abnormal

What exactly do you mean by this? Assuming at this point you've captured the users credentials, how do you then turn around and use them to actually perform SSO? There's no way for your server to authenticate with those credentials in a way that sets the correct cookies in the user's browser, which is important for SSO to work.

Really, if you were going to execute this kind of attack, it would be better to fake the SSO as well, or omit it entirely, and just store the credentials for later retrieval.

But, none of this is specific to OAuth or SSO itself. It's just a phishing attempt, no matter how its initiated.

| improve this answer | |
  • By emulate the user, I mean I use their username and password my app stole to do the app authorization as far as google is concerned. That way, they can see that my app is "registered". – Andrew Hendrix Jan 18 '17 at 18:23
  • Maybe I should've ask a different question then. "Does OAuth / SSO make phishing attempts easier?" – Andrew Hendrix Jan 18 '17 at 18:25
  • 1
    No, it doesn't. It makes it harder, since you need to do more work. – Mike Caron Jan 18 '17 at 19:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.