An idea for a browser anti-phish feature

March 27, 2008

Here's a somewhat naive idea for a browser anti-phish feature that might actually work, at least until phish spammers started getting really creative in various ways, sparked by yesterday's entry.

First, let's start with the twin observations that the real goal of anti-phish efforts is to avoid you entering your bank login and password anywhere except on your bank's site, and that people notice the presence of things much more easily than they notice the absence of things.

(Hence, among other things, the underwhelming success that SSL has played in stopping phishing; quick, notice that the padlock has not been shown in the URL bar. When the padlock often isn't.)

So let's take the goal as a literal thing. Have the browser remember your sensitive logins and passwords, along with the websites that they're supposed to be used on, and whenever you enter both into a form on any other website the browser pops up a big 'WHOA THERE' warning.

(For obvious reasons, the browser would store the login and password hashed and salted.)

This doesn't need website or user involvement to collect the basic information; the browser can passively build an index of sensitive logins and passwords by using the 'do not remember this field' flag that banks and other places set on their forms.

The downfall of this trick comes when phishers start prompting for your login and password using something besides simple forms, ranging from the very basic 'please email us your account information' approach through having JavaScript-based data entry instead of plain forms on their phish pages.


Comments on this page:

From 60.234.141.149 at 2008-03-28 03:37:26:

Why not have a master password for your browser, and have the browser take the password entered in the <input type="password"> form, the master password, the url, and hash them all together and send that to the website in place of the password entered.

Thus a phisher needs to learn the master password, the url, and your password. Since not even the user knows the password that the browser is submitting the phisher can't convince the user to tell them. The master password perhaps is never prompted for, except as a "initial configuration" type thing, so most users will have probably forgotten it even if the phishers manage to convince them to tell them what it is.

This also has the advantage of not requiring storing of any state about which websites and passwords you're using. Although there are a lot of negatives still. If you lose your master password (hdd crash?) you lose access to /all/ your sites. Some password entry boxes are for passwords you also enter in places that aren't browsers. I can see rolling over your master password being annoying. Two URL's can refer to the same page (www.example.com and example.com), to be fair this often trips up SSL sites too.

-- PerryLorier
By cks at 2008-03-28 20:55:36:

There are a number of problems with your idea, but one of the big ones is that it requires websites to update their authentication systems (and to support what will at first be a marginally popular feature). Any new web thing that requires widespread adoption to be useful is pretty much dead on arrival.

From 60.234.141.149 at 2008-03-30 02:03:49:

The website wouldn't see anything different. They'd just see that the password entered by the user was some random string that didn't correspond to the actual password entered by the user. The only thing that would need updating is the users browser, and only that users browser (although that user would always have to use an updated browser, since it's the browser that knows how to generate the password that was actually submitted in the POST)

-- PerryLorier
From 207.88.115.107 at 2008-04-02 12:28:40:

I think this is an excellent idea and would be trivial to implement. The only downside is you add another attack vector by creating the hash file (against which an attacker can use a rainbow table to crack weak passwords).

Chris: How does the browser know which field is used for the username? Regardless, I do not think it is necessary to track the username, only password form elements. Prior to POST, the browser would only need to calculate the hash and then determine if the site has been previously associated with the hash (this makes for a cheap lookup too). "Warning: This is the first time you have used this password with 192.0.2.10. This may be an attempt to steal your password. Blah blah blah."

Perry: I think the idea is the POST would be held back unless the user agreed to use the password with the new site.

From 207.88.115.107 at 2008-04-02 12:31:15:

Just realized that you specify salt and hash. Good man!

Cheers,

Ian

By cks at 2008-04-02 20:09:03:

PerryLorier: aha, my misunderstanding of your idea; that makes it much more feasible. I still see some problems, like how to deal with a place changing how you log in enough that the generated hash changes.

Ian: Most login forms I've seen only have two text fields, so I'd just make the browser hash all text fields together, but you're right; just hashing the password alone is more reliable, and it deals with some simple ways to defeat the scheme.

Written on 27 March 2008.
« Why authenticated email won't stop phish spam
The stages of Bittorrent encryption »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Thu Mar 27 23:32:10 2008
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.