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

On 2 October 2014 05:15, Daniel Cheng <dcheng@google.com> wrote:
> Doesn't adding this new input type defeat the whole point of ignoring
> autocomplete=off? Now sites that want to disable password managers will just
> use this for their password field, and we're back to square one.

Right and at what point does this end? If for our situation we're
forced to create our own masking solution which doesn't use a password
input, isn't a logical extension that some of these sites which been
trying to prevent password managers filling actual password fields
will just use this technique too?

On a slight tangent, as an avid 1password user I appreciate this
functionality of password managers to complete irrespective of what
the field says. But I disable the ability of the password manager to
auto-fill without my explicit input because I faced this kind of
issue. Perhaps the UX of auto-filling these fields could be considered
in a different way - all of these problem areas are on pages where the
user clearly knows they don't need their password filling in *any* of
the fields on the form so if made clear to them, wouldn't consent to
it.

Dan

>> On Wed, Oct 1, 2014 at 12:19 PM, Dan Poltawski <dan@moodle.com> 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 Thursday, 2 October 2014 06:55:18 UTC