Re: Defending users of unprotected login pages with TrustBar 0.4.9.93

Gerv, many thanks, this was very useful - see comments below and in particular, an idea I had, after thinking of your comment below, on possibly better approach to the `really unprotected pages`... Amir

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

Amir Herzberg wrote:
> 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)
> <http://wamu.com/securityandprivacy/security.asp#Phishing>,

Really?
https://login.personal.wamu.com/logon/logon.asp?dd=1

> Zions
> <http://www.zionsbank.com/home.jsp>.

How about:
https://banking.zionsbank.com/zfnb/logon/user

Great; I'll add these two... Of course I still have some other pages in my `Hall of Shame of unprotected login pages` for which we don't (yet?) know an https (ssl) alternate. I agree that many of them may have alternates and it may be `just` a bit of work to find them - if you or others can find that'll be great... but I'm sure you agree we have also to think of solution - if we can - to pages for which a secure alternate is not found.  

But, if you do find some without secure login forms, I think the right
approach here is to shame them into submission. There's only so much you
can do to compensate for their inadequacies.

Well, shame them - how? I would think the Hall of Shame is about the best I know how to do. I would appreciate help in making this shameful situation more visible to the public... For example, maybe you (and other security-concious folks) can link to the Hall of Shame from relevant webpages and articles.

BTW, I found the above two by viewing the HTML source and messing around
accessing some of the URLs or domains in the form without any parameters.

> 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;

How could you prevent compromise of the signature if the page was
compromised?

This is actually easy. The server digitally signs the page and puts the signature in the page; TrustBar (or browser) can easily validate the signature, using the public key of the server (of course extracted securely from a certificate signed by a trusted CA). So this is as secure as SSL. But does require site cooperation, of course.

> 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.

Sure - absolutely. This is supposed to be constructive criticism :-)

Definitely is, and thanks again.

How about the following refinement...

Suppose that whenever a user assigns name/logo to an unprotected page, we also save a copy of that page, and compare such copies for five accesses (or over a period of at least five days). If we find the page is static (except possibly for few bytes here and there), we will add the page to our `static login pages repository` (we also save the changing locations so we can ignore them later). Upon reloading same page, we check if there are changes from the archived version (in locations which we did not mark as changing). So far this is essentially what I've described before.

The difference is in what we do if the page does change (in new locations). What I think of doing is simply to *display the archived version* - with a message / button allowing user to use the new version instead if needed. I think in most cases, even if there are changing fields in the page, using the old version will still work.

What do you think? Amir

--

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