OAuth and phishing vulnerabilities, are they inexorably related to each other?

Question

I recently worked with OAuth, and I have to say that I really like it. I like the concept, and I like how it provides a low level of access for your users to connect external data to your site (or to provide apis data for external consumption). Personally, I always refused sites that ask me to provide my login for another website directly to them. And the OAuth approach for the "valet for the Internet" perfectly solves this problem.

The biggest problem that I (and many others) see with it is the standard OAuth workflow, which encourages the same type of behavior that takes advantage of phishing attacks. If you train your user to be redirected to the site to provide login credentials, then the phishing site easily uses this usual behavior, but instead redirects them to its clown site, where they record your username and password .

What if something you did (or saw done) to alleviate this problem?

• Do you inform users to enter and enter the login to the providing site manually, without automatic links or redirects? (but then it increases the barrier of entry)

• Are you trying to educate your users, and if so, when and how? Any long security explanation the user must read also increases the barrier to entry.

What else?

Answer 1

I believe that OAUth and phishing are inexorably related, at least in the current form of OAuth. Systems were created to prevent phishing, most HTTP messages (pause for laughter ...), but obviously this does not work.

Phishing is a very successful attack on systems that require username and password combinations. As long as people use usernames and passwords for authentication, phishing will always be a problem. The best system is to use asymmetric cryptography for authentication. All modern browsers are built in to support smart cards. You cannot phish a card sitting in some wallet, and hacking the user's desktop will not leak the secret key. An asymmetric key pair does not have to be on a smart card, but I think that it is building a stronger system than if it were purely implemented in software.

Answer 2

Do you have an account on the site that you are redirected to, should they not implement anti-phishing measures, such as signature phrase and image? It also uses any existing training that users have received from, for example, banks, which usually use these measures.

In general, the login page should provide the user with understandable shared secrets to confirm the identity of the site they enter.

As Jingle points out, an ssl certificate can be used for authentication, but in this case, the user cannot download the certificate directly from the site into his web browser as part of the OAuth installation process? If a trust relationship has already been established with the site, I’m not sure that further CA assistance is needed.

Answer 3

There are some methods that you can use to prevent or reduce phishing attacks. I made a list of cheap options:

• Mutual identification resources. Ex icon associated with a specific user, displayed only after the user enters his username.
• Using usernames is not deterministic and avoid emails as usernames.
• Enable the option for the user to see his login history.
• QRCode, which allows authentication in a device pre-registered as smartphones. Like the whatsapp website.
• Show authentication numbers on the login pages, which the user can confirm on the official website of the company.

All of the above parameters are highly dependent on user training on information security and privacy. Wizards that appear only on first authentication can help achieve this goal.

Answer 4

To expand the analogy with the valet: how do you know that you can trust the valet and that he / she is not just someone trying to do it? You really do not do this: you simply make this (perhaps unconscious) judgment based on context: you know the hotel, you are there before, you can even recognize the person to whom you give your key.

In the same way, when you log in using OAuth (or OpenID), you redirect the user to a site / URL that they should be familiar with, as they provide their credentials from this site, which is known to be theirs.

Answer 5

This is not just an OAuth problem, but also an OpenID problem. Worse, of course, with OpenID you provide your ISP’s website, it’s easy to automatically clear this website if you don’t already have a fake one, and generate the one you will then direct your user to.

I am fortunate that nothing serious uses OpenID for authentication - blog posts, flickr comments are simply not a juicy goal.

Now OpenID goes somewhere in the direction of mitigation, as they begin to develop support for their information card, where a fixed user interface in the form of client software will provide a wallet certificate that is secure, but MS seems to have dropped the ball on information cards themselves. although this is their (open) specification.

In the near future it will not disappear.

Answer 6

How to certify an oAuth provider just like an ssl certificate? Only a certified oAuth provider is trustworthy. But the problem is that, as with ssl certification, CA matters.