- From: Mike West <mkwst@google.com>
- Date: Thu, 16 Oct 2014 10:11:34 +0200
- To: "Eduardo' Vela <Nava>" <evn@google.com>
- Cc: WHAT Working Group Mailing List <whatwg@whatwg.org>
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