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

On Thu, Oct 16, 2014 at 10:36 AM, Eduardo' Vela" <Nava> <evn@google.com>
wrote:

> 1. How are keyup/down/press restrictions useful for password protection?
> Actually they seem more useful for CSRF instead.
>
These events are some of the many ways in which the data being typed into a
particular field is exposed to script. If we're going to call the field
writeonly, we need to lock those down. That said, they only protect that
particular field: attackers can easily bypass this restriction by doing
more work (overlaying a new form, etc).

How are they useful for CSRF? I don't see the link.

> 2. How is the tainting problem simplified by focusing on write only?
>
 Focusing on autofill means that we're moving the flag up to the
credential, so we can ensure that the browser only autofills into writeonly
form fields. To your specific example, it means we don't have to care about
blobs in iframes, because (I'm pretty sure...) we don't autofill blobs in
iframes.

> 3. How is tagging the credential as write-only help with the secure
> deployment of a site-wide CSP policy?
>
It doesn't. The two are completely unrelated.

My point was simply that if we tag a credential as writeonly, we wouldn't
fill it into a form that lacked the writeonly flag in a page that lacked
the writeonly CSP. Solving CSP deployment isn't a precondition of this
scheme.

> 4. Why are sites that echo passwords in password fields shooting
> themselves in the foot?
>
> Echoing sensitive data in a place where an injected XHR can read it is a
general problem. This proposal doesn't make that worse.

> Imagine if the password manager, instead of just syncing passwords around
> also moved an httpOnly cookie. And whenever it detects the password going
> by it appends the httpOnly cookie.
>
> If the server detects such cookie in the request it concatenates it after
> the password and uses that as the auth credential.
>
> On the server, this only requires a one line change (adding he cookie at
> the end if present), on the client the APIs already exist.
>
> Same can be done with Channel ID with the further advantage that the OBC
> can't be copied. The advantage of the cookie approach is that it can be
> morphed and generated more easily.
>
Sounds like a great way of hardening sign-in. It's not clear to me how that
negates the problem of password theft, as I'd still need to be able to sign
in on my friend's computer when I accidentally spill coke on my laptop,
right?

> Also, as a point of reference we've redone authentication many more times
> in a lot less time with a lot less resources than deployed CSP across all
> of Google. So yes, it's easier.
>
That surprises me.

Still, I suspect both are significantly more work than adding an attribute
to a form field.

--
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 Thursday, 16 October 2014 10:00:14 UTC