RE: TrustBar and insecure sites of PayPal, MS Passport, Yahoo!, Chase, ...

["Yvan G.J. Boily" <yboily () seccuris com>]

Responses inline. 

> I think you will agree, that this statement is based on your intuition 
> rather than on real research and data. My intuition is different: I 
> believe that by presenting a sufficiently simple interface, even most 
> naive users will be able to detect a spoofed web page (e.g. as result of 
> phishing attack). But I am also conducting experiments to validate my 
> (or your) intuition; preliminary results seem to support my belief. 

Yes, this is my opinion, and I don't have concrete research or data to support it.

My opinion is, however, based on several years of experience working to educate users about security while working in 
technical
support and later when interacting directly with my own clients and explaining how security works.


> Also, I think that you should, in fairness, try our tool (TrustBar) to 
> evaluate whether it may help (naive, off-guard and savvy) users. I am 
> very interested in your evaluation (although, based on your notes, it is 
> unlikely to be very excited...)....

Well, I am not terribly excited because I have tested it.  There are some significant issues with it; 

1. When I go to a site that does not need encryption (i.e. www.google.com) the Trustbar says boldy: "This site is not 
protected".
This message does not change and remains static.  It rapidly fades into the background and lacks relevance.  For 
security features
to work they need to appear when there is an exception and have the ability to be monitored.  For the average user if a 
security
notification becomes ubiquitous it becomes "normal" and therefore not worthy of attention.  The occasional message box 
that is
*helpful and informative* is far more likely to attract the interest and engage the user.  From a user interface design 
it is not
very effective in this regards.

2. The premise of your tool is based on a theory that I view as fundamentally flawed.  Again, I apologize if this 
sounds harsh, but
in order for this tool to be effective the user must navigate to a *spoofed site* which attempts to use SSL.  Simply by 
virtue of
the fact that most sites will have displayed the ubiquitous error message your tool will be obviated because it 
specifically
requires that SSL be implemented to notify the user of a change in the "protected" status.  Combine this with the fact 
that the
*vast* majority of sites do not use SSL for the primary login page, and only engage SSL when a user submits an 
authentication form,
and you have a tool that will be essentially ineffective in the face of current practices.

3. The tool itself has fairly obvious bugs.  After going from E-Bay's sign in page and being told that the site is 
Identified, I
immediately navigated to a site that I set up with an invalid SSL certificate (Firefox complains a lot about it in 
fact).  Sadly,
the trustbar allows the site with the invalid certificate to inherit the Verified property of Ebay's site.
http://yboily.is-a-geek.net/galleries/trustbar for visuals and a play by play.

> > Your trust bar is simply a trivial extension of features that already exist,
> > and will certainly be useful enough for users with the knowledge and
> > awareness to understand what it is to look for,
> Well, that's already something, isn't it?

I won't dispute the value of having that information available; the issue is that your utility takes a widely accepted 
process for
performing web based authentication and states broadly that it is insecure without offering any validation or 
explanation for the
statement.  Your opinion on the need for what you deem "protected" authentication is highly subjective, and 
contravenese an accepted
practice with little to know benefit.

That said, when you do present said information it is *CRUCIAL* that the information be accurate.  The bug I have 
identified is a
fatal flaw in that the application directly promotes a false sense of security.  I realize that this is a bug and can 
be fixed in a
future release, but this bug completely circumvents, using the situation it is intended to protect against, the 
protections offered
by your application.

This combined with the inability of the tool to actively protect against spoofed sites that do not attempt to use SSL 
undermines any
value I would see from a security perspective.

> > but popping up messages saying things like "Warning: this page is not protected", 
> > without offering further information to improve awareness, or a more 
> > meaningful message poses the same risk.  
> I quite agree with you here. We should - and will - add information 
> explaining what an `unprotected site` means and what the user can do.

The problem is that again, you are playing off of a non-issue; this tool will only (in theory) protect you from a 
spoofed site that
uses certificates that are invalid.  If the certificates are valid then it counts on the user knowing enough to 
identify a
fraudulent CA, and if SSL is not used, then the ubiquitous message will not change which will not likely attract the 
users
attention.

In your research paper associated with this application you clearly assert that:

http://www.cs.biu.ac.il/~herzbea/Papers/ecommerce/spoofing.htm
Detection of irregularity principle: computer users often do not read contents of informative fields and messages, and 
may not
detect an irregular text in them. However, users are usually able to detect an irregular, unexpected sensory experience 
(graphics,
sound etc.).

By including the ubiquitous message you dilute the value of warning a user of a potential security hole.

> > This is especially so when you are referring to a standard
> > practice which does not pose a credible risk.
> But it does! Unprotected login pages are, well, unprotected, and 
> therefore could be spoofed without this being noticed by most (naive) 
> users - and this will happen even if these users use TrustBar which 
> allows them to easily identify (protected) pages (and avoid spoofed 
> versions of them).
> > As security professionals we have an obligation to reduce the dilution of
> > security warnings, and to demystify the warnings we release.  People with
> > knowledge in a field *must* apply that knowledge and filter the output of
> > that knowledge so that people outside of the field can understand the most
> > relevant information.  Doctors, Pharmacists, Lawyers, Financial Analysts,
> > Accountants, and numerous other publicly accessible professions build
> > careers on translating jargon into language people can use and work with.  

> With this I completely agree and this is part of the contribution of 
> TrustBar... (try it and you'll see what I mean)

No, I have tested it.  Your application introduces more jargon, and even worse, leaves messages such as "Warning: this 
page is not
protected" for anything that the authors (you) have decided to label as insecure.

The concept of displaying the certificate credentials is certainly useful, but it, in and of itself, increases the 
usage of jargon
and the knowledge a user must have as the user moves from having to understand how to identify a certificate that is 
valid for the
site to requiring at least a general understanding of how certificates work, including understanding the relationship 
between
certificate authorities and individual certificates.

> > If everyone in the security field starts hanging off lamp-posts and
> > screaming the world is going to end, no-one is going to take us seriously,
> Hey, what are you talking about? I just pointed out these pages are 
> unprotected, and that's a fact.

That they are unprotected by your definition is a fact.  Wether or not the lack of SSL certificates truly impacts the 
effectiveness
of phishing attacks remains to be seen.  It is important to note that SSL encryption is not as frequently noted for its 
absence by
average users; it is more frequently noted by its presence as virtually all major browsers add visual cues.  If a user 
lacks the
awareness to identify these cues when following a link then they are just as likely to fall victim to a phishing attack 
hosting
invalid SSL certificates as they are to fall victim to a non-encrypted attempt.

> > and no one is going learn anything because people tend to shy away from
> > hysterics.  Discussing potential threats in a theoretical context is
> > valuable so that we can develop skill-sets, but creating and releasing tools
> > that are little more than UI fixes and billing them as security tools is
> > bordering on negligent.

> I disagree; I think secure UI is a critical element of security.

A secure user interface that can reliably present correct, factual, and useable information is crucial maintain 
security.

Your tool is neither an effective security tool, nor is it an effective UI enhancement.  The lack of documentation, or 
a clear and
compelling argument as to the security implications of "unprotected" sites combined with the assertion of your 
application that
virtually all sites but those that register certificates that your application can recognize are unprotected generates 
an
environment that promotes ignorance and fear.

Added to this is the "Suspect Fraud" button which is neither documented, nor does it have any useful function (the code 
is identical
to the code for the cancel button!); it simply allows the user to continue using the site without any additional 
information etc..

Your tool fails as an effective UI extension due to the lack of documentation, and is ineffective (from a flawed 
implementation
perspective) and, in my opinion, flawed in its underlying design and intention.

Again, I apologize if it sounds harsh, but it is also my opinion that security tools must be judged harshly.

Regards,

Yvan