W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2013

Re: Passsword managers and autocomplete='off'

From: Maciej Stachowiak <mjs@apple.com>
Date: Fri, 13 Dec 2013 00:47:04 -0800
Cc: WebApps WG <public-webapps@w3.org>
Message-id: <36C33748-6199-4AB0-8DD5-DB7DF29B2BE3@apple.com>
To: Joel Weinberger <jww@chromium.org>

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.

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.
(2) Casual walk-up attacks, for example temporary access to a friend's or relative's computer. AKA "friendly fraud".

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.

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.

Received on Friday, 13 December 2013 08:47:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:20 UTC