7

I've been doing a fair bit of work with OAuth recently, and I have to say that I really like it. I like the concept, and I like how it provides a low barrier-of-entry for your users to connect up the external data to your site (or for you to provide the data apis for consumption externally). Personally, I've always balked at sites that ask me to provide my login for another website to them directly. And OAuth "valet key for the web" approach solves this nicely.

The biggest problem I (and many others) see with it though, is the standard OAuth work-flow encourages the same type of behaviors that phishing attacks use to their advantage. If you train your user that it is normal behavior to be redirected to a site to provide login credentials, then it is easy for a phishing site to exploit that normal behavior but instead redirect to their clone site where they capture your username and password.

What, if anything, have you done (or seen done) to alleviate this problem?

  • Do you tell the users to go and login to the providing site manually, without automatic links or redirection? (but then this increases the barrier of entry)

  • Do you attempt to educate your users, and if so, when and how? Any lengthy explanation of security that the user has to read also increases the barrier of entry.

What else?

Matt
  • 41,216
  • 30
  • 109
  • 147

6 Answers6

2

I believe that OAUth and phishing they are inexorably linked, at least in OAuth's current form. There have been systems in place to prevent Phishing, most notability HTTPs (pause for laughter...), but obviously it doesn't work.

Phishing is a very successful attack against systems that require username/password combos. As long as people use usernames and password for authentication phishing will always be a problem. A better system is to use asymmetric cryptography for authentication. All modern browsers have built in support for smart cards. You can't phish a card sitting in someones wallet and hacking the user's desktop won't leak the private key. The asymmetric keypair doesn't have to be on a smartcard, but I think that it builds a stronger system than if it where purely implemented in software.

rook
  • 66,304
  • 38
  • 162
  • 239
1

There are some techniques that can be used to avoid or diminish phishing attacks. I made a list of cheap options:

  1. Mutual identification resources. E.x. icon associated with a specific user shown only after user input his username.
  2. Use of usernames not deterministic and avoid emails as usernames.
  3. Include option to user see his login history.
  4. QRCode that allows authentication in device pre-registered like smartphones. Like whatsapp web.
  5. Show authentication numbers in login pages that the user can validate in the official company site.

All options listed above highly depends on user education about information security and privacy. Wizards that appears only on the first authentication can helps achieve this goal.

Anderson Marques
  • 808
  • 8
  • 13
1

You have an account with the site you are being redirected to, shouldn't they be implementing anti-phishing measures such as a signature phrase and image? This also leverages any existing training the users have received from e.g. banks who commonly use these measures.

In general, the sign-in page should present user-friendly shared secrets to the user to confirm the identity of the site they are logging into.

As Jingle notes, a ssl certificate could be used for authentication, but in this case couldn't the user load a certificate directly from the site into their web browser as part of the OAuth setup process? If a trust relationship has already been established with the site, I'm not sure further resort to a CA is necessary.

Kevin Granade
  • 1
  • 3
0

To extend the valet analogy: how do you know you can trust the valet, and that he/she is not just someone trying it on? You don't really: you just make that (perhaps unconscious) judgement based on context: you know the hotel, you've bene there before, you might even recognise the person to whom you're giving your key.

In the same way, when you sign in using OAuth (or OpenID), you are redirecting the user to a site/URL which should be familiar to them, seeing as they are providing their credentials from that site which is known to them.

davek
  • 22,499
  • 9
  • 75
  • 95
  • The site should be known to them, but that's how phishing works - they create a look-a-like clone. I suppose ultimately it is up to the user to be smart, but doing what we can to mitigate the problems can go a long way sometimes. I just don't know what exactly we can do for OAuth/phishing... – Matt Feb 01 '10 at 20:52
0

This isn't just an OAuth problem, it's OpenID's problem as well. Worse of course with OpenID you're giving a web site your provider, it's easy to automatically scrape that site if you don't have a bogus one already and generate one which you then direct your user too.

It's lucky that nothing serious uses OpenID to authenticate - blog posts, flickr comments just aren't a juicy target.

Now OpenID are going somewhere to mitigation as they start to develop their Information Card support, where a fixed UI in the shape of client side software will provide an identity "wallet" which is secure, but MS appear to have dropped the ball themselves on Information Cards, even though it's their (open) spec.

It's not going away anytime soon.

blowdart
  • 55,577
  • 12
  • 114
  • 149
0

What about to certify the oAuth provider just like the ssl certification? Only certified oAuth provider is trustworthy. But the problem is, as with ssl certification, the CA matters.

Jingle
  • 53
  • 1
  • 6