Re: Passsword managers and autocomplete='off'

On Tue, Dec 17, 2013 at 2:12 PM, Maciej Stachowiak <mjs@apple.com> wrote:

>
> 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.
>
My apologies; originally I looked at the document Ian referenced (
http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#attr-fe-autocomplete),
but when asked, I did a quick search and pulled up the first thing I saw
:-)
>
>
>
>> 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<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 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.
>
I certainly agree, and that's partly why we've now released the flag to
users to turn off autocomplete='off' if they so choose.

>
> On the other hand, if all browsers collectively chose to completely ignore
> autocomplete=off, that might allow proceeding more aggressively.
>
Sure, and that's why we're bringing it up with the standards body. Before
we proceed any further, we want to make sure that (a) our intention is
known, and (b) make sure we're not missing anything critical. So far, the
arguments in favor of autocomplete='off' are pretty much as we already
understood them.

Ultimately I certainly don't expect every browser vendor to act in an
identical way immediately, but I am simply hoping to start a conversation
about the standard.

>
> Regards,
> Maciej
>
>
>
>
>
>