RE: Password Manager Support

>From the user perspective, password managers (and especially those that
generate unique passwords for the user transparently) create an
interesting usability issue, in that the consumer is generally tied to
the machine where the password is generated and stored.

A password manager must account for the user ability to carry their
credentials with them between machines . . . A feature I have yet to see
implemented outside of the synced "keychain" concept on the Mac platform
(which has its own unique set of 'challenges').  

We must also tackle the issue of security of the credential store at
rest between machines and compatibility of the credential store between
different password managers and platforms.

Robert W Capps II
Chief Technologist,
Electronic Fraud Research Group
World Savings Bank, FSB



-----Original Message-----
From: public-usable-authentication-request@w3.org
[mailto:public-usable-authentication-request@w3.org] On Behalf Of George
Staikos
Sent: Tuesday, April 11, 2006 9:53 AM
To: public-usable-authentication@w3.org
Subject: Re: Password Manager Support


On Monday 10 April 2006 13:31, Thomas Roessler wrote:
> Hello,
>
> another item that came up as a possible work item during the workshop 
> is form filler / password manager support: Could web forms that are 
> used to provide login functionality be annotated with information that

> makes it easier for form-fillers and password management tools to do 
> their task?
>
> The design space in this area is rather large; it ranges from 
> low-resistance microformat-like annotations to deeper changes to 
> mark-up.
>
> Your thoughts on possibly promising directions for this kind of work 
> would be most welcome.

  We [KDE] have something called KWallet which allows auto-form-fill of
password login forms on web pages as well as applications.  The wallet
is locked with a master password and stored in an encrypted file.  In
order to determine if we -should- prompt for the master password, we
store hashes of the access keys (form URLs) unencrypted.  If a hash
match is found, we prompt.  There is a small leak of information here,
but it's not nearly as bad as storing all this information in plain text
and gets us a decent user experience.

  Problems we have:

1) It's very tied to KDE and only starts after the KDE session starts.  
Hopefully we can extract this for KDE4.
2) Our UI and application integration leave much to be desired.  This is
just a matter of developer-hours to fix.
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
4) We don't support multiple logins per form well (at all)

  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).

--
George Staikos
KDE Developer				http://www.kde.org/
Staikos Computing Services Inc.		http://www.staikos.net/



*****************************************************************************
If you are not the intended recipient of this e-mail, please notify 
the sender immediately. The contents of this e-mail do not amend 
any existing disclosures or agreements unless expressly stated.
*****************************************************************************

Received on Tuesday, 11 April 2006 19:36:05 UTC