Browser-based mitigation of phishing attacks

The OpenID phishing issue is a hard one to solve, particularly because it aims to:

  1. be user-friendly, i.e. it should pass the mother-in-law test; and
  2. work on the web platform without special software or browser plugin

So, why is this suddenly a problem?

Not really, phishing is a perennial problem on the Internet that researchers and developers have been trying to solve for many years now. OpenID just accentuates it because RPs are unregulated. You don’t need any agreement with any OP, essentially anyone can set up a web site and put the OpenID login button. If OpenID takes off, RP sites will grow like ‘shrooms and user will get used to the idea that if they see the OpenID logo, they can type their URL to login. This only makes it harder for users to discern the good RPs from the bad ones.

This is really a social problem, and not a fault of the OpenID protocol. Users need only to trust their OP, and not the RPs that they interact with. If a rogue RP sends you to a page the poses as your OP but the URL doesn’t match your OP’s, you bail out. Doesn’t that sound simple? Well, the cold hard fact is that phishing works and there are research1 to prove that people get tricked very easily.

Numerous ideas to mitigate phishing attacks have been floating around the OpenID list and on the OpenID mini-blogsphere. Ben Laurie argues for a client-side solution:

Authentication on the web is broken, and has been for a long time. The OpenID fanboys want OpenID to work on any old platform using only standard software, and so therefore are doomed to live in the world of broken authentication. This is fine if what you protect with your OpenID is worthless, but it seems clear that these types of protocol are going to be used to authenticate for things of value.

This is the root of the problem: if you want to protect anything of value, you have to do better than existing Web solutions. You need better client-side software.

The picture is not so sunny, however, because most users:

  • won’t know / bother to install specialized plug-in or upgrade their browsers unless they’re forced to
  • won’t know the difference between citibank.com/signon and citibank.com-banking-foobar.com

And even if they installed those anti-phishing toolbars and what not, they still fall for it!

While I can’t decipher the wirings of the mums-and-dads who fall prey for phishing attacks, I know that I get lazy sometimes and just don’t bother. Then I remember this little trick that Firefox introduced to ensure that users get the warning before installing extensions — Introduce a delay in the dialog box before it can be dismissed. That sort of worked for me, at least for that 5 seconds I can’t click so I might as well read a little.

So, here’s an idea for a browser (or plug-in) implementation:

FUNCTION form.onsubmit()
  IF !form.contains-password-field()
    RETURN ok
  END IF

  IF form.action.domain IN trusted-domains
    RETURN ok
  END IF

  SHOW WARNING-DIALOG (delayed-dismissal=5 secs)

  IF continue-button.clicked
    ADD form.action.domain TO trusted-domains
    RETURN ok
  ELSE // cancel-button.clicked
    RETURN not-ok
  END IF
END FUNCTION

The idea is that you should only submit passwords to sites that you have previously added to the trusted-domains list. This idea is not new, and has been proposed by several on the OpenID list.

Where I think could really make a difference is the way in which WARNING-DIALOG is constructed. It should contain the following:

  • If the current page and the form target page are on different “effective domain”, emit warning. There are legitimate use cases for this, and we don’t want to overemphasize it, but it should raise suspicion.
  • Display the “effective domain” of the form prominently.
  • If the form target is not a HTTPS URL, emit warning.
  • Warn the user that the target is not known to the browser to be trusted, and that this could be a sign of phishing.
  • A continue button that is greyed out for 5 seconds to force the user to read the above information.
  • A cancel button that is focused by default so hitting enter will dismiss the dialog and cancel the request.

An “effective domain” as I call it is defined as the DNS name in the URL stripped of insignificant parts. This basically means that we can use Mozilla’s Effective TLD Service that I blogged about earlier to summarize a URL for display to the user so that us.rd.yahoo.com becomes just yahoo.com, and it will correctly work for things like www.netbank.com.au, which returns netbank.com.au instead of com.au.

A sample dialog might look like:

You are submitting a password to a site that may not be safe. Click “continue” to trust this site forever, or “cancel” to return to the current page.

Password will be sent to: xn--pypal-4ve.com
Password will be sent in the clear (unencrypted).

  

There are a few advantages to this proposal:

  • it works on all password forms, not just for OpenID
  • it forcefully disrupts the flow of the user and the delay may help the user to be more cautious

The downsides are:

  • it only works for password phishing, other information such as credit card numbers will go through without warning
  • phisher can replace the password input field with javascript / DHTML / flash to bypass the check

Even with these restrictions, I still think that it brings significant value in terms of mitigating password phishing attacks. This is of course very raw and there is much room for improvement. All comments and suggestions are welcome.

1 Thanks to Mike Beltzner for the links to these phishing research papers.

UPDATE: Kim Cameron’s latest blog post about Integrating OpenID and CardSpace has some nice pictures of the modal OpenID phishing attack scenario.



5 Responses to “Browser-based mitigation of phishing attacks”

  1. =marcin Says:

    I posted my remarks to list, but I’ll repeat them here. In my opinion it is not the issue of effectiveness of warning. While idea of “delay box” is good, the problem noticed here:

    “phisher can replace the password input field with javascript / DHTML / flash to bypass the check”

    is more vital. My idea is: if phisher wants to bypass the check, we should warn the user. How? By NOT changing browser UI.

    So my idea is: let’s change browser UI in a significant, visible way on every page that contains password field. Let’s warn users if password field looks suspicious. And let’s NOT change UI if it’s not a password field. User will notice the difference.

  2. 3247 Says:

    Your example shows the domain name in ACE format (xn--pypal-4ve.com). This is only a good idea if the real domain is not an IDN.

    For users of legitimate serves not using pure-ASCII domains, this will make any comparision impossible.

  3. wil Says:

    @Claus:

    This is just how Firefox displays IDNs where the TLD is not on their whitelist (and “.com” is not.) For IDNs on the whitelist, this will render properly in Unicode.

    I should have made this clear and show just an ASCII case, thanks for the clarification.

  4. Kim Cameron’s Identity Weblog » Can browser-based plugins solve the phishing problem? Says:

    [...] Dready blog proposes writes about OpenID phising and proposes a browser plugin that introduces a delay in the dialog box before it can be dismissed. The OpenID phishing issue is a hard one to solve, particularly because it aims to: [...]

  5. oficina mecanica Says:

    I think it is a very good post. It helps us many away. So many many thanks for this article.