Re: Secure Metadata

I would tend to agree with Jeffrey Altman's points.  Logos are trivial
to spoof using a simulated browser window, like the window-in-window
attack.  Therefore, logos can not be trust indicators.

Further, training users to recognize a spoofable indicator distracts
the user from reliable trust indicators, such as a Secure
(unspoofable) Chrome.  I'm sure this could be demonstrated in
usability studies, since giving the user a false trust indicator
(logos) alongside a postive trust indicator (unspoofable UI) would
surely lead to confusion among some non-zero number of users.

This goes back to some fundamental assumptions.  Traditionally, static
browser chrome was though to be unspoofable due to the browser
security model.  Pragmatically, due to [many] bugs, popups, and
window-in-window attacks, we must stop assuming that browser chrome
can not be arbitrarily spoofed.  We must assume every pixel on the
display is spoofable.

However, Secure Metadata may be applied in other areas, such as
providing a domain trust model.  We don't necessarily need to surface
this through logos.

  - Jeff




> On 2006-04-14 10:36:46 -0400, Jeffrey Altman wrote:
> > Message-ID: <443FB37E.7070008@secure-endpoints.com>
> > Date: Fri, 14 Apr 2006 10:36:46 -0400
> > From: Jeffrey Altman <jaltman@secure-endpoints.com>
> > Organization: Secure Endpoints Inc.
> > User-Agent: Thunderbird 1.5 (Windows/20051201)
> > MIME-Version: 1.0
> > To: public-usable-authentication@w3.org
> > Subject: Re: Secure Metadata
> > References: <8A794A6D6932D146B2949441ECFC9D680216C8C1@msgswbmnmsp17.wellsfargo.com> <200604121353.13002.staikos@kde.org>
> > In-Reply-To: <200604121353.13002.staikos@kde.org>
> > X-Enigmail-Version: 0.94.0.0
> > Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060807040501070303070304"
> >
> > George Staikos wrote:
> > > On Wednesday 12 April 2006 13:49, Michael.Mccormick@wellsfargo.com wrote:
> > >> RFC 3709 (http://www.ietf.org/rfc/rfc3709.txt) defines an X.509
> > >> extension that allows optional logographic images for community, issuer,
> > >> and subject organizations.
> > >>
> > >> Say for example GM obtained web server SSL certificates from VeriSign
> > >> for use within their supplier community.  The cert could display logos
> > >> for GM, VeriSign, and the auto parts exchange (or any subset /
> > >> combination thereof).
> > >
> > >   Right... but the question is, do we fill the chrome with all of these
> > > things? :-)  This is a lot of real-estate, it's a potential new phishing
> > > vectors, and it's going to be really hard to remove one day when we decide
> > > that problems 1 and 2 are too much to handle.
> >
> > I'm extremely concerned that the use of logos will cause users to pay
> > even less attention to differences in URLs when evaluating certificates..
> > I'm going to pick on Mars Incorporated and to a certain extent Verisign
> > today quite a bit simply because there is a case that I can use as an
> > example that is readily available.
> >
> > The URL https://chillinforamillion.com is secured by a valid certificate
> > issued by Verisign's "VeriSign Class 3 Secure Server CA".  This is an
> > intermediary CA whose certificate is not shipped as a trust anchor in
> > FireFox.  The expectation is that the intermediate certificate is
> > supposed to be supplied by the web server.  The installation
> > instructions are found on VeriSign's web site here:
> >
> > http://www.verisign.com/support/ssl-certificates-support/install-ssl-certificate.html
> >
> > Unfortunately, it is too often the case that web site managers don't
> > understand that intermediary CA certs need to be installed on the server
> > and so users are displayed the famous "Website Certified by an Unknown
> > Authority" dialog.
> >
> > If the user were to examine the certificate they would find that the
> > Common Name is in all upper case while the web site url hostname is in
> > all lower case causing the user (including myself) to think that the
> > problem is a case comparison error and ignoring the details surrounding
> > the Issuing Certificate Authority certificate BECAUSE the certificate
> > was issued by VeriSign, Inc.; it must be good.  Besides I see these
> > dialogs all the time when I go to blogs protected by self-signed certs
> > and web sites that are mis-configured such as the one from Mars Inc.
> >
> > Now if you were to throw logos at me in this dialog I would see a logo
> > from Mars Inc. (did I even know that Mars Inc made skittles and
> > starburst?) and a VeriSign logo.  As documented in "Fast Food Nation" we
> > are programmed from a very early age to trust brands and one of the
> > strongest associations that we have is with the brand logo.  Companies
> > spend tons of money every year re-enforcing the association that their
> > logo represents products that are safe, wholesome, etc.  When users see
> > the VeriSign logo and see the McDonalds logo on a page they are going to
> > feel safe and secure and they are only going to be more likely to go
> > ahead and press that "Accept this certificate" button.  Using logos to
> > reduce the details provided to the user is not a means of increasing
> > security.
> >
> > The only benefit that I can see from displaying logos is that when a
> > logo that a company has spent billions of dollars maintaining starts
> > to be used as part of phishing attacks it is going to get a lot of
> > attention from CEOs, corporate legal teams, and law enforcement because
> > when a brand is damaged it is damaged not only for web transactions
> > but will become a part of the public consciousness associated with that
> > brand every time a consumer considers purchasing a product or service.
> >
> > While displaying logos may appear to be a good thing in the short term,
> > I am skeptical of the long term security benefits.
> >
> > Jeffrey Altman
> >
> >
> >
>
>
>
>
>

Received on Wednesday, 26 April 2006 06:30:44 UTC