RE: Rough proposal: Contextual Password Warnings

Thomas, please add this to the wiki area so it can be scheduled for a 
"lightening discussion" with other recommendations this month. 

http://www.w3.org/2006/WSC/wiki/RecommendationIndex

          Mez

Mary Ellen Zurko, STSM, IBM Lotus CTO Office       (t/l 333-6389)
Lotus/WPLC Security Strategy and Patent Innovation Architect




"Doyle, Bill" <wdoyle@mitre.org> 
Sent by: public-wsc-wg-request@w3.org
03/26/2007 11:05 AM

To
"Thomas Roessler" <tlr@w3.org>, <public-wsc-wg@w3.org>
cc

Subject
RE: Rough proposal: Contextual Password Warnings







 
Thomas,

In looking at the page, could be that the code uses multiple URLs and
password fields are used in a way that could be determined to be a
security issue. This may also work with context that I think Tyler has
been talking about user determined "safe" sites.  Something in the
order of - any page with a password field is compared against URLs or
pages that are marked in the user agent as "restricted" or "safe" and
attempt to determine discrepancies. If someone else does not jump in, I
will go to the sites and look at the code later and see if what pops
up.

Bill D.


-----Original Message-----
From: public-wsc-wg-request@w3.org
[mailto:public-wsc-wg-request@w3.org] On Behalf Of Thomas Roessler
Sent: Monday, March 26, 2007 7:01 AM
To: public-wsc-wg@w3.org
Subject: Rough proposal: Contextual Password Warnings


Preparing for a talk, I'm going through some of our SharedBookmarks.

Xia and Brustoloni had a paper, Hardening Web Browsers Against
Man-in-the-Middle and Eavesdropping Attacks, at WWW 2005.  In that
paper they report successful user studies with two techniques:

- Context-Sensitive Certificate Verification

The success here is not that surprising, since there's actually no
user override, but instructions for users how to obtain necessary
information to secure their clients.  I'm not sure how scalable that
really is.

- Specific Password Warnings

This one focused on telling people very explicitly that they were
submitting passwords in an unencrypted manner; they were looking for
"password" type input fields (the starred ones).


The flixster story that hit Slashdot today [1] makes me wonder if
there is a somewhat more general good practice around helping users
understand when they are submitting passwords "differently." I'd be
curious to hear more about what's actually been implemented and/or
tested in this space.

1.
http://www.theinternetpatrol.com.nyud.net:8080/is-flixster-a-big-fat-sp
ammer-are-they-hacking-your-aol-or-hotmail-address-book

The idea would be to trigger very specific warnings when, e.g.,

- people submit passwords unencrypted that have only ever travelled
  thorugh TLS

- people submit passwords to a site with a different TLS "identity"
  (the petnames notion of "identity" might be appropriate here)

- people try to submit passwords through forms (or some script reads
  a form field, for that matter) that were used with secure password
  protocols before.

Thoughts?
-- 
Thomas Roessler, W3C  <tlr@w3.org>