- From: Eduardo' Vela\ <evn@google.com>
- Date: Thu, 16 Oct 2014 12:16:35 +0200
- To: Mike West <mkwst@google.com>
- Cc: WHAT Working Group Mailing List <whatwg@whatwg.org>
On Thu, Oct 16, 2014 at 11:59 AM, Mike West <mkwst@google.com> wrote: > 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). > 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 computer? > 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:17:21 UTC