Re: Passsword managers and autocomplete='off'

Thanks for the feedback, everyone. A few people at this point have
suggested emailing the whatwg@whatwg.org list since this is really an HTML
feature; I'll do that in a few. In response to Ian's question, I'm
referring to the W3 WebForms standard:
http://www.w3.org/Submission/web-forms2/#the-autocomplete

I've also inlined some responses to Maciej below.


On Fri, Dec 13, 2013 at 12:47 AM, Maciej Stachowiak <mjs@apple.com> wrote:

>
> On Dec 12, 2013, at 11:20 AM, Joel Weinberger <jww@chromium.org> wrote:
>
> > Hi all. For a while now, we have wanted on Chrome to ignore
> autocomplete='off' for password fields for the password manager. We believe
> that the current respect for autocomplete='off' for passwords is, in fact,
> harming the security of users by making browser password managers
> significantly less useful than they should be, thus discouraging their
> adoption, making it difficult for users to generate, store, and use more
> complex or (preferably) random passwords. Additionally, the added benefit
> of autocomplete='off' for security is questionable at best.
> >
> > We believe that our implementation of this ignore functionality actually
> falls within the letter of the web-forms standard. A user's password save
> for an autocomplete='off' field requires a user interaction to save (we do
> not do it automatically), which ultimately is not different than a
> "copy/paste" approach from the user. Additionally, we have taken
> precautions against password harvesting via XSS. We do not autofill into
> the DOM until the user has made a gesture (click, keypress, etc.) within
> the page, and we never autofill into iframe forms (we wait for a user to
> explicitly select their username from a dropdown).
> >
> > Part of the issue here is that autocomplete='off' is overloaded. It is
> simultaneously meant to denote a "secure" or "sensitive" field *or* that a
> field's completion will be handled by the application itself. Thus, we are
> not proposing to ignore autocomplete='off' for our form fill as there are
> many places where the application itself creates a suggestion box, and we
> have no desire to override that functionality. Rather, we care about the
> "sensitive" use, which in the case of password fields, is already denoted
> by the input type='password'.
> >
> > In the latest version of Chrome (currently in our Canary build), we have
> already implemented this feature. However, we will putting in behind a flag
> shortly so that it is not the default, but to still allow users to opt into
> this. We hope to make this the default for users in the not very distant
> future.
> >
> > What are this group's thoughts on this? Any particular concerns with
> this approach? While we believe that we are within the letter of the
> standards in our approach, we would love to see this made explicitly clear
> in the standards and hopefully see other browsers adopt this in the future,
> as we believe it is in the security interests of all users.
>
> Safari has similar behavior available as anon-default user preference:
> "Allow AutoFill even for websites that request passwords not be saved."
> Even with this setting enabled, some user interaction is required both to
> save and to fill. We agree that on net, refusing to autofill passwords
> harms security.
>
As of yesterday, in Chrome Canary, it is now a flag that users can turn on
as well. Not quite the menu option it is in Safari, but an option
nonetheless.

>
> We did not make it the default, because website owners have objections to
> bypassing autofill=off as a default behavior. The primary types of
> objections are:
>
> (1) "Public computer" scenarios. Accidentally saving a password on a
> shared or public computer may endanger the user's account.

The browser saving passwords seems like the least of concerns with public
computers :-P From our perspective, given that key loggers etc are a big
threat on a public computer, we don't consider the benefit here to outweigh
the overall user benefit of having managed passwords.

>

(2) Casual walk-up attacks, for example temporary access to a friend's or
> relative's computer. AKA "friendly fraud".
>
Similar to the public computer case, from our perspective, this benefit
doesn't seem to outweigh the benefit of having more complex, managed
passwords.

I should also mention that, in general, Chrome explicitly does not consider
a physically local attacker in our threat model.

>
> At least some website operators (often for financial or shopping sites)
> are more worried about these threats than about the risk of users using
> lower quality or shared passwords passwords. This factor is magnified in
> Safari where we suggest autogenerated per-site random passwords, but only
> if we can autofill them.
>
This is precisely our concern. We believe the priorities of website
operators are badly misplaced. There is a huge amount of evidence of the
problems with non-complex passwords (see various password database leaks of
late), and extremely low evidence of the prevalence of these various local
attacker threats. We applaud Safari's generated password management and
believe it is the best interest of our users to make their passwords more
complex for all of the web.

It's also the case that by prioritizing the request of the website over the
desire of users to manage their passwords, we are violating the Priority of
Constituencies<http://www.schemehostport.com/2011/10/priority-of-constituencies.html>.
I suppose that by offering a flag we are somewhat skirting around that, but
I don't consider it a real option.

>
> I do not know if we can collectively assuage the worries of sites that use
> autocomplete=off. So far, though, I'm not aware of any complaints about our
> non-default setting to bypass it.

I'm not sure we can convince website operators of anything like this
without making the change happen and demonstrating the world won't
collapse. I suspect that a lot of this is a fear of the unknown.

>
> Regards,
> Maciej
>
Thanks a lot for the comments, Maciej!