W3C home > Mailing lists > Public > public-wsc-wg@w3.org > November 2006

ACTION-9 (misuse/misappropriation of padlock icon)

From: Michael(tm) Smith <mikes@opera.com>
Date: Tue, 21 Nov 2006 21:09:27 +0900
To: public-wsc-wg@w3.org
Message-ID: <20061121120924.GF4348@malware>
This is my response for ACTION-9 (Formalize the use case of content
providers using the same icons as are typically used in the
"chrome area" and thus diluting the meaning of such visual aids).

First, note that George Staikos, Bob Lord (from Red Hat), and Amir
Herzberg have all written about this with much more insight than I
can hope to. This is my attempt at a nutshell description.

  Content providers (typically bank sites) have login pages which
  lack SSL/TLS security and for which browsers do thus not display
  a padlock icon in the taskbar. Lacking that padlock indicator in
  the browser chrome, many of these same sites instead display a
  padlock icon somewhere in the actual login page content (near
  the login form). That represents a misappropriation of the
  convention of the padlock as a trust/security indicator -- a
  misuse designed to give the user a greater sense of security but
  that actually only gives users a /false/ sense of security.

  This problem devalues attempts of browser vendors and security
  experts to educate users to "check for the padlock". Users begin
  to trust any page that displays a padlock icon somewhere on the
  page -- even if the browser address bar displays no padlock
  (because that's that these bank sites are teaching them to do).

  That in turn makes it much easier for fraudsters to construct
  phishing sites that have login pages with the same level of
  apparent trust value as the actual bank login pages (that is,
  pages for which no lock icon is displayed in the browser address
  bar but that have a lock icon on the phishing page in exactly
  the same place the real bank-site login page has its padlock).

Examples from Bob Lord
  Not secured through SSL/TLS, but note the padlock on the login
  form. Click on that padlock to get a misleading "just trust us"
  explanation to users -- which any phishing site can mimic just
  as easily as they can the site's misuse of the lock icon.

  No SSL/TLS, padlock icon right next to words "Log On"

Bob's comment:
  Even pros cannot tell the difference between real sites and phishing
  sites as long as the real sites behave like phishing sites.

Example from George Staikos:
  Login page for Air Canada site. No SSL/TLS, but note the padlock
  icon and statement, "Your personal information is encrypted..."

Examples from Amir Herzberg:
  No SSL/TLS, padlock icon above login form, click on padlock icon to
  see misleading "just trust us" explanation similar to Chase site.

  Page only partially secured with SSL/TLS, padlock on login form.
  (Note that KDE Konqueror does recognize this page a partially
  secure and shows a padlock icon in the normal browser-chrome
  address bar area; click that and Konqueror indicates "Some of
  this document is secured with SSL, but the main part is not.")

See also Amir Herzberg's Phishing and Spoofing FAQ:


Especially see the question, "My bank's site says 'protected by
SSL' and/or displays padlock sign; is it protected?"


Amir's answer:
  Unfortunately, several sites - including some major bank sites,
  e.g. Chase - present a padlock and/or otherwise claim to use SSL
  and cryptography to protect the login process, while actually
  only encrypting the password in transit using a script in the
  login page... if the user received a spoofed login page, this
  will not be visible; of course, the spoofed page will send the
  password to the attacker.

And more good writing on this topic by Bob Lord on his blog:


Especially these entries:

  Banks are a Phisher's Best Friend

  Phishing and SSL

By the way, from Bob also quotes from the following paper (which I
would guess at least a few of you have probably already read):

  Aaron Emigh, "Online Identity Theft: Phishing Technology,
  Chokepoints, and Countermeasures"

That's it.


Michael(tm) Smith
Opera Software, Tokyo

Received on Tuesday, 21 November 2006 12:09:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:14:12 UTC