Re: [whatwg] Password managers ignoring autocomplete='off' harming security

On 2 October 2014 00:34, Gavin Sharp <> wrote:
> The underlying use case seems to be obfuscating text in an input field
> that isn't a password. From a spec perspective, a feature to opt-in to
> obfuscation that isn't type=password could address this (e.g.
> type="masked-text").

Yep, exactly. Thanks for putting it more eloquently than me!

On 2 October 2014 00:34, Gavin Sharp <> wrote:
> On Wed, Oct 1, 2014 at 4:17 PM, Peter Kasting <> wrote:
>> So, you're doing both of the following?
>> * Using a password field for (sometimes) things that aren't passwords
>> * Storing (potentially) sensitive data in the clear yourself, and sending
>> it (again, in the clear) to other accounts/machines
> I probably shouldn't speak for Dan, but I think you're
> misunderstanding the use case here (particularly with characterization
> #2). The data being intentionally stored in these fields is not
> "sensitive", in the sense that it can't be shared in the clear to
> other users (teachers), it just needs to not be displayed on the
> screen (where it can be viewed by students).
> That browsers now automatically go fill in sensitive data (passwords)
> into these password fields is the issue, because people might not
> notice that happening and then submit the form.



> Gavin
> On Wed, Oct 1, 2014 at 12:19 PM, Dan Poltawski <> wrote:
>> Hi All,
>> Over the past few months all the browser vendors have moved towards
>> ignoring autocomplete="off" with password fields. I understand the
>> rationale behind this, but in our software project this has lead to
>> the frustrating situation where we seem to have no good option to deal
>> with this and the change is actively harming the security of our
>> users.
>> To outline the situation in broad terms:
>> * We have shared secrets on the page which we protect against shoulder
>> surfing by using the password element with autocomplete="off"
>> * The password managers are now all auto-filling these fields with
>> passwords on the same domain and in many cases without the user even
>> noticing (optional fields they wouldn't look at)
>> * The passwords then get stored in our shared-secret fields clear text
>> and available to all their peers
>> * This can then be used for privilege escalation etc
>> It seems like our only option is avoid use of password field at all
>> and invent our own 'fake' password field to protect our users
>> passwords from being exposed. That seems like a really disappointing
>> solution.
>> (Apologies in advance if this is completely off-list, I saw some
>> threads leading to this list and it wasn't clear to me if this sort of
>> discussion was acceptable).
>> cheers,
>> Dan

Received on Wednesday, 1 October 2014 23:49:06 UTC