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

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

> Yea the keyup/down/press restrictions are definitely not useful, at least
> for password protection since the user has clearly no way to know if the
> field is safe or not.
>

I'd disagree that they're useless, but they're certainly not a robust
defense against an attacker reading information that you type into a form.


> The tainting is never gonna work reliably and consistently as Michal hinted
> (say, a blob: URL would run in the same origin but not be bound to CSP
> which could be used to exfiltrate the data).
>

The tainting problem is simplified by focusing on the part I care about:
autofill.


> The dependency on CSP also makes this a bit aspirational. I can agree that
> the login form could be CSP protected but the whole origin is not as
> likely. Specially for connect- and form-.


As noted in a previous response, I see these concerns as somewhat mitigated
by tagging the credential as writeonly in a way that would prevent autofill
into a read/write form.


> And even that might be insufficient (its a common practice to echo back
> typed passwords when the user doesn't answer a captcha or has it wrong, for
> example - a same-origin XHR will leak the password).
>

As I think you'd agree, those pages are already shooting themselves in the
foot. You're correct that this proposal doesn't solve their problems, but
that's not a unique disadvantage of the proposal. :)

There are other solutions that seem more likely to work to solve the
> problem of password managers (something like a synced channelId, for
> example, or even FIDO style solutions). This proposal seems to try to
> achieve a mixture of just replacing canary values at the network layer
> based on destination with an httpOnly-style model for user-supplied data.
>

1. Password managers aren't the problem. Especially when used to generate
even vaguely secure password, they make authentication on the web
significantly less insecure than it would otherwise be.

2. The various proposals on http://www.browserauth.net/ like channel-bound
cookies (which I think you're referring to above?) can solve cookie theft.
They don't solve password theft.


> If we have a password manager and are gonna ask authors to modify their
> site, we should just use it to transfer real credentials, not passwords..
> Passwords need to die anyway.
>

You ding CSP as a "bit aspirational", and then propose killing passwords.
*cough* :)

As long as "modify their site" means "type 11 characters into your site's
template" and not "rewrite your authentication stack from the ground up
using technologies you've never heard of", I think it's something we can
reasonably ask of authors. The central advantage of the writeonly proposal
is that it's a trivial drop-in change. It's certainly not the real
revolution in authentication that we desperately need on the web, but
that's a feature, not a bug. :)

-mike

--
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 08:12:23 UTC