W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2014

Re: [whatwg] Proposal: Write-only submittable form-associated controls.

From: Mike West <mkwst@google.com>
Date: Fri, 17 Oct 2014 11:38:57 +0200
Message-ID: <CAKXHy=crUSSpCJHNFMZuRpUWBNg9RP0pmSY8eiU_FJStCLry_A@mail.gmail.com>
To: "Eduardo' Vela <Nava>" <evn@google.com>
Cc: WHAT Working Group Mailing List <whatwg@whatwg.org>
On Thu, Oct 16, 2014 at 4:28 PM, Eduardo' Vela" <Nava> <evn@google.com>
wrote:

> Well, it doesn't today. But maybe you mean in the future.
>

You're right, sorry. I was thinking of blob-based workers. Maybe we should
do the same for frames?


> But the point is that there are many ways to exfiltrate, these are just
> the first thing that comes to mind but others like <input pattern> also are
> an info leak, and I mean, these are just ideas coming up the top of my
> mind, the browser wasn't designed to solve this problem and it's dubious if
> it's really feasible to do so without reinventing a lot of things.
>

http://mikewest.github.io/credentialmanagement/writeonly/#input-behavior
outlines a few mechanisms, and potential resolutions. `pattern`, for
instance, is addressed by blocking input validation on the form field.

As you suggest, I'm sure there are more mechanisms. I don't think there are
infinite mechanisms, however, and I'm fairly certain that we could address
those that exist.


>
>
>> I wasn't clear: the server still needs to accept a bare username/password
>> pair, as it's not the case that users only log in a) using a password
>> manager, b) on a machine that's syncing. As long as that's the case, I
>> don't see how tying passwords to a cookie makes password theft less
>> problematic.
>>
>
> The user would just have to type the full password (including the extra
> cookie-random value that the password manager backed up). The caveat of
> course is that the user has to write this suffix somewhere, but that is
> what makes the password strong anyway.
>

I don't think asking users to remember a password and a random value is
tenable.


> And anyway, to be clear, this is just a discussion on an alternate design
> that has the same properties and is significantly easier to implement for
> both, authors and UAs, but it's by no means the only solution. My point is
> that there are probably simpler solutions that have similar security
> guarantees.
>

I'll reassert that this proposal is simpler for authors (11 character
opt-in) and users (no change) than the scheme you just outlined. It's more
complex for browser vendors, but that's fine and expected, as we're way
down at the bottom of the priority heap.

--
Mike West <mkwst@google.com>
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Received on Friday, 17 October 2014 09:39:45 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:24 UTC