Re: Solutions to phishing and to site spoofing

[Michael Silk <michaelsilk () gmail com>]

Hi Amir,

> >       If so, it seems to be the same old story of education when
> > implementing it ... i.e. that users need to be educated to care enough
> > to look at it and consider it before typing in a password.
>
> Do you suggest to educate users to validate domain names and certificates?
        
 Of course not ... I suggest to devise a system where the users don't
have to learn
 anything at all.
        
 I.e. like the "client authenticated ssl" Rogan and others discussed,
or the original
 email system I proposed.
        
        
> But also, I'm not sure you are right; users care about protection only
> for few sites, and so I think they'll get used to ignoring TrustBar's
> warning in sites where they don't care about security.
        
 But they won't really care for _any_ site.
        
 Consider if I am a user and want to make a transfer to pay some bill
someone has
 been hounding me about.
        
 If I go to the bank and don't see TrustBar, or I see it displaying
"INSECURE SITE"
 I probably won't care or notice because I am more concerned with
solving my bill
 issue.
 
 Or, consider if the phished site says something like:

-------------------------------------------------------------
Hi,
 Due to recent security upgrades we have removed the TrustBar
 from our site and implemented a more secure system.
 
 Blah blah ...
 
 Please login below:
-------------------------------------------------------------

 Not that a user would really read it anyway, but if they did it would take a
 really switched-on user to realise a warning like this is fake. And infact, it
 might not even be fake - TrustBar may have security issues initially requiring
 it to be taken down or disabled by administrators.

-- Michael
 

On Wed, 01 Dec 2004 12:25:32 +0200, Amir Herzberg <herzbea () cs biu ac il> wrote:
> Michael Silk wrote:
>
> > Hi Amir,
> >
> >       I read paper (btw: did anyone else find the text was overlapping in
> > some places ?) 
> Sorry about that - directed pointers will be appreciated.
>
> > but I had a bit of difficulty understand exactly what
> > TrustBar does.
> >
> >       Correct me if I'm wrong, but does it simply make the "Secure"
> > indicators of a site more obvious? And provide a way to put a logo
> > outside the web page?
> It does a bit more. In particular, by presenting the logo or name of
> organization in TrustBar, this information is authenticated - while in
> the web page, the spoofer/phisher of course display the logo and name of
> the victim organization/site; SSL merely authenticates the URL (and most
> users don't understand the structure of URLs enough to detect attack).
>
> Furthermore, TrustBar presents also the name or logo of the certificate
> authority (CA - the entity that identified the owner of the site).
> Browsers, by default (which essentially nobody changes), accept
> certificates from over 100 CA's, which users are not aware of (and
> therefore don't trust). In this, TrustBar really fixes an error in the
> trust management of browsers, rather than just improve UI.
> >       If so, it seems to be the same old story of education when
> > implementing it ... i.e. that users need to be educated to care enough
> > to look at it and consider it before typing in a password.
> Do you suggest to educate users to validate domain names and certificates?
> >       Again, correct me if I'm wrong but wouldn't it also display "WARNING:
> > THIS PAGE IS NOT PROTECTED" for every single non-ssl site? This, IMO,
> > would make that warning almost useless as users would learn to ignore
> > it.
> This could be annoying to some users, as pointed out by Will Pittenger.
> So, while we currently always display the warning, we plan to later
> eliminate it, possible after some training period (in which users become
> aware that all sites without a logo in the TrustBar area are
> unprotected), and in a way which will prevent spoofing of TrustBar in an
> unprotected page (there are some tricky things here).
>
> But also, I'm not sure you are right; users care about protection only
> for few sites, and so I think they'll get used to ignoring TrustBar's
> warning in sites where they don't care about security. But, we'll have
> to do more experimentation to find out who is right about this.
>
> Thanks for your comments... Amir Herzberg
>
>
> > -- Michael
> >
> >
> > -----Original Message-----
> > From: Amir Herzberg [mailto:herzbea () cs biu ac il]
> > Sent: Tuesday, 30 November 2004 6:27 PM
> > To: webappsec () securityfocus com
> > Subject: Solutions to phishing and to site spoofing
> >
> > Re Michael's proposal
> > (http://michaelsilk.blogspot.com/2004/11/article-solution-to-phishing.html):
> >     I agree with others that it is not reasonable to build security on
> > (insecure) e-mail. In particular I agree with Rogan: if you are
> > willing to have users install private/public key pair, with public key
> > known to server, then you can authenticate the user using SSL/TLS
> > client authentication - no need for passwords at all, very convenient
> > (once the keys are installed as I wrote above).
> >
> > Finally, I also agree with Mark Burnett, who said:
> >
> >  > Protecting authentication credentials is also a problem, but the  >
> > solution to phishing is more one of authenticating the site rather  >
> > than authenticating the user. First solving the issue of  >
> > authenticating the site makes it easier to solve the problem of  >
> > authenticating the user.
> >
> > Let me add that site authentication is also important when clients
> > cannot be authenticated, e.g. by a web store prompting for credit card
> > or other personal details, or a source of sensitive information, e.g.
> > software download or financial information. Site authentication is the
> > basic function of SSL/TLS, but I believe it is currently poorly
> > implemented, since the UI is not visible enough, and since browsers
> > trust many certificate authorities that users are not even aware of.
> > We have some initial survey results which support this strongly.
> >
> > I will appreciate your feedback on TrustBar, our proposal (and
> > implementation) of a browser add-on (hopefully to be integrated with
> > future browsers), to address these concerns. You can download TrustBar
> > from http://TrustBar.MozDev.org for Mozilla and FireFox; the open
> > source code should also be there soon (or e-mail me to get it). Or
> > read about it and  about the secure UI principles and research
> > (including survey) behind it at
> > http://www.cs.biu.ac.il/~herzbea//Papers/ecommerce/spoofing.htm.
> > I am trying to arrange an IE implementation (any takers?)
> >
> > Best,
> >
> > Amir Herzberg
> > http://AmirHerzberg.com
> > Associate Prof., Computer Science Dept
> > Bar Ilan University
> >
> > .