W3C home > Mailing lists > Public > public-usable-authentication@w3.org > April 2006

Re: Password Manager Support

From: Thomas Roessler <tlr@w3.org>
Date: Fri, 14 Apr 2006 17:13:13 +0200
To: George Staikos <staikos@kde.org>, "Capps, Robert, BKOF" <RCapps756@Worldsavings.com>, Michael.Mccormick@wellsfargo.com
Cc: public-usable-authentication@w3.org
Message-ID: <20060414151313.GX28531@lavazza.does-not-exist.org>

On 2006-04-11 12:53:23 -0400, George Staikos wrote:

> 3) Some forms make it very difficult to make this work
> 	3a) Script changing the form after page load
> 	3b) Script changing the form field contents dynamically for "security"
> 	3c) Just plain weird usage of forms
> 	3d) Dynamically changing URLs


>   Yes, we could improve forms for this.  One thing that
> would be nice is to have forms that explicitly state that
> they are "wallet-appropriate".  Right now we have to guess,
> and the guessing doesn't always work right (see #3 above).

Additionally, there is of course any number of login-like forms
that aren't recognized properly by the form fillers that are
currently out there -- e.g., some get confused about which
login and password fields belong together; there are composite
login fields; and so on; there are "login" forms that ask just
for a password; etc.

I could imagine some work on annotations that could help take
care of these sets of problems, and hence move form-fillers out
of the area of second-guessing what sites want.  More reliable
form-fillers could then be a useful contribution in mitigating
those kinds of phishing attacks that attempt to get hold of
online login credentials.

In scoping this kind of work, we would need to think carefully
about which questions benefit most from a consensus answer --
and which ones may more be in the realm of decisions that
vendors make.  A very narrow scope could, for instance, focus
on defining simple login form annotations, microformat style,
and could rule any questions about the security of password
stores and best practices for form fillers' user interaction
out of scope.

Some reactions to this strawman would be most useful.

On 2006-04-11 18:02:39 -0500, Michael.Mccormick@wellsfargo.com wrote:

> Behavior of browser form & password autofill features should
> be configurable to both the end user and the web site.  If
> either the user or the site disables an autofill preference,
> the autofill should not happen.

This would be a requirement for the annotations discussed

> Browsers that offer autofill features (esp. for passwords)
> should be required to meet some minimal standards for
> protecting the cache where they're stored on the user's
> computer, such as encryption with a key unique to that user
> which is known only to the browser.

> Browser or OS install wizards should ask if the computer is
> public or not, and if so all autofill features should be
> disabled by default.  Autofill at airport kiosks and
> Internet café PCs represents a common attack vector.

I wonder how to best accomodate these kinds of discussions --
they don't really fall into the realm of interoperability work,
but much more in general best practices for vendors.  Further
input welcome!

Thomas Roessler, W3C   <tlr@w3.org>
Received on Friday, 14 April 2006 16:23:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:53:15 UTC