Re: Passsword managers and autocomplete='off'

On Dec 17, 2013, at 11:21 AM, Joel Weinberger <jww@chromium.org> wrote:

> 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

That is pretty out of date and not a standards track document.


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

To be clear, I'm not saying I agree with these reasons. But these are the reasons some major financial or shopping sites state when asked why they use autocomplete=off. We have mentioned counter-arguments nearly identical to what you say, and in most cases, the site operators were not persuaded. (We did not say we explicitly don't consider physically local attackers, as we do give it some consideration; though obviously we cannot protect against a sufficiently determined attacker with physical access.)

I also forgot to mention:
(3) At least some sites believe that consumer finance regulations require them to use autocomplete=off. They believe their requirement to protect the user's authentication information and prevent it from being accessed by third parties extends to preventing passwords from being automatically stored on the user's computer.

> 
> 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. 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. I suppose that by offering a flag we are somewhat skirting around that, but I don't consider it a real option.

I largely agree with this.

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

The sites that are concerned about password autocomplete have at least two possible actions they could take that made us hesitant to flip the default:

(A) They could blacklist browsers that ignore autocomplete=off - this has been explicitly threatened in the past. It's also been claimed that, even if the sites did not want to do this, regulatory bodies would require them to do so because of point #3 above.

(B) They could reimplement password input from scratch (using script and not using a real password field) in a way that evades browser autocomplete heuristics. This would be bad because it would prevent even off-by-default autocomplete=off bypass from working.

For these reasons, we initially made an off-by-default preference to allow autocomplete=off bypass, and explicitly chose not to call attention to it on an autocomplete=off page. However, we do tell users when we would have generated a password, but avoid doing so because the site prevents autocomplete.

As a future step, we're considering telling users about the bypass setting, or even giving a direct link to it, on sites where autocomplete=off prevents us from doing something.

We expect proceeding incrementally is more likely to make the other parties involved more comfortable about the process.

On the other hand, if all browsers collectively chose to completely ignore autocomplete=off, that might allow proceeding more aggressively.

Regards,
Maciej