Re: Defending users of unprotected login pages with TrustBar 0.4.9.93

On 9/19/05, Gervase Markham <gerv@xxxxxxxx> wrote:

Amir Herzberg wrote:
> 1. TrustBar will automatically download from our own server,
> periodically, a list of all of the unprotected login sites, including
> any alternate protected login pages we are aware of. By default,
> whenever a user accesses one of these unprotected pages, she will be
> automatically redirected to the alternate, protected login page.

I like this idea a lot...

Thanks! Try it, it works nicely. I actually use one of these sites personally...

> 2. TrustBar allows users to assign a name or a logo to sites, protected
> or not (to help users identify fake sites). We now added a mechanism
> computes a hash of every unprotected site for which the user has
> assigned name/logo. TrustBar compares this hash on subsequent accesses
> to the same site. If the site is not modified in five subsequent
> accesses, TrustBar begins displaying `Same since <date>`; and when the
...
...but don't like the principle of this one. Trying to work out which
changes are safe and which are not is a very risky business indeed - and
without that, it won't work very well in practice.

I quite agree, that this idea is more problematic. However, we are still giving it a try, since some sites simply do not offer a protected login at all, or at least we haven't found one, e.g. Washington Mutual (WaMu), Zions. Also note, that while this idea is problematic without any help from the servers, the idea could work quite well to authenticate pages if the server cooperates and provides e.g. signature on the page; this may solve some scenarios where sites prefer not to use SSL on login pages for performance and other considerations (hosting...). We didn't implement this yet since there will be no immediate value to users.

How is the user
supposed to translate a last-modified date (which, BTW, already arrives
in an HTTP header) into a level of risk?

The last-modified in HTTP header is not secure so we can't rely on it...
But yes, I agree this is not so user friendly. Well, we are doing research, so we can do some imperfect stuff (ok even lousy stuff), maybe we or others see how to improve it, and we can always remove it. While I do think browsers should already consider adopting the main, proven ideas in TrustBar, I definitely do not suggest adopting this mechanism as it is now...

They can't remember exactly
what the entire page looked like last time they visited, so if it's
changed recently, they have no clue if it's a risky change or not.

They definitely are not supposed to look at the page to see if it is wrong. The hope is that they may be more alert, maybe some will look at the html source (there are hackers everywhere...), or at least use tools to see where the form goes to; others may contact their bank and ask... Ok, again, I'm not sure this thing will help...

Thanks for the feedback! Amir

--

Amir Herzberg
Associate Professor, dept. of Computer Science
Bar Ilan University
http://AmirHerzberg.com