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

On Oct 1, 2014 4:34 PM, "Gavin Sharp" <gavin@gavinsharp.com> wrote:
>
> Firefox developer here (I was involved in our behavior change). Sorry
> to hear that it's causing you trouble. Unfortunately this seems like a
> pretty specific, uncommon use case, so we hadn't considered it. And we
> probably aren't reasonably able to fix things for you without breaking
> other more common use cases we care about (people using password
> fields for passwords).
>
> 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"). From your perspective, I suppose you could work
> around this by obfuscating the text in the field yourself rather than
> letting the browser do it.
>
> Gavin

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.

Daniel

>
> 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 04:15:26 UTC