RE: Rough proposal: Contextual Password Warnings

Providing the ability to delegate rather than sharing a password would be
preferable for a number of reasons.

-----Original Message-----
From: public-wsc-wg-request@w3.org [mailto:public-wsc-wg-request@w3.org] On
Behalf Of Thomas Roessler
Sent: Monday, April 23, 2007 2:55 PM
To: Mary Ellen Zurko
Cc: wdoyle@mitre.org; public-wsc-wg@w3.org
Subject: Re: Rough proposal: Contextual Password Warnings


Discharging ACTION-197 (but not in the Wiki, yet, since I'm offline).

- Hal pointed out that password sharing across different sites -- as
  undesirable it might be -- is an *extremely* common habit, and
  needs to be accommodated.  It was proposed that a contextual
  password warning feature might be adapted to recognize the
  distinction between passwords that are readily shared, and
  passwords that aren't.

- Stuart noted that recognizing a password requires that it be typed
  in wholly; however, a malicious site might circumvent that by
  transmitting the password back character by character.
  
  (He's right about that, and this probably kills the obvious
  technical implementation of the proposal.  There might be room if
  something like Tyler's PII bar took off, which I'm a little
  skeptic about.)

Source: http://www.w3.org/2007/04/11-wsc-minutes

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





On 2007-03-29 08:02:59 -0400, Mary Ellen Zurko wrote:
> From: Mary Ellen Zurko <Mary_Ellen_Zurko@notesdev.ibm.com>
> To: wdoyle@mitre.org
> Cc: public-wsc-wg@w3.org, Thomas Roessler <tlr@w3.org>
> Date: Thu, 29 Mar 2007 08:02:59 -0400
> Subject: RE: Rough proposal: Contextual Password Warnings
> X-Spam-Level: 
> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.1.5
> 
> 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>
> 
> 
> 
> 

Received on Monday, 23 April 2007 21:38:10 UTC