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

On Thu, Oct 16, 2014 at 11:59 AM, Mike West <> wrote:

> On Thu, Oct 16, 2014 at 10:36 AM, Eduardo' Vela" <Nava> <>
> 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).
OK, so it's just being locked down out of a formality, but has no security
purpose. Sure, so it's not useful for any security purposes.

How are they useful for CSRF? I don't see the link.
Let's not go into it. But if you lock down an origin as described in the
spec, and send a FormData via XHR then one could authenticate an action
came as a result of a user action. Anyway, I shouldn't have said that, the
solution is incomplete since value="" prefilling would also have to be
disabled for that to work.

> 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.

The blob: URL would simply steal the FormData from the other page (it's
same origin), and submit it via XHR to another origin..

> 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.

I see, so it wouldn't be sufficient to make a field writeonly, you would
also need to declare that in the CSP. The whole website would have to have
connect-src policies stricly restricting the exfiltration of data from the
domain. Is there any (relevant/important) website where locking down
connect-src for the whole origin is possible or feasible? Or are we
assuming every website has their login form in a unique origin? (Are you
expecting to have per-page suborigins implemented before this is feasible?).

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.

Sensitive data is echoed in places where XHRs can read all the time. Your
email, your authentication credentials (OAuth, etc), your bank statements.
This isn't a general problem.

> 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?

How is the password manager able to sync your password to your friend's

> 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 <>
> Google+:, 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:17:21 UTC