On Thu, Oct 16, 2014 at 4:28 PM, Eduardo' Vela Nava e...@google.com
wrote:
Well, it doesn't today. But maybe you mean in the future.
You're right, sorry. I was thinking of blob-based workers. Maybe we should
do the same for frames?
But the point is that there are many ways to exfiltrate, these are just
the first thing that comes to mind but others like input pattern also are
an info leak, and I mean, these are just ideas coming up the top of my
mind, the browser wasn't designed to solve this problem and it's dubious if
it's really feasible to do so without reinventing a lot of things.
http://mikewest.github.io/credentialmanagement/writeonly/#input-behavior
outlines a few mechanisms, and potential resolutions. `pattern`, for
instance, is addressed by blocking input validation on the form field.
As you suggest, I'm sure there are more mechanisms. I don't think there are
infinite mechanisms, however, and I'm fairly certain that we could address
those that exist.
I wasn't clear: the server still needs to accept a bare username/password
pair, as it's not the case that users only log in a) using a password
manager, b) on a machine that's syncing. As long as that's the case, I
don't see how tying passwords to a cookie makes password theft less
problematic.
The user would just have to type the full password (including the extra
cookie-random value that the password manager backed up). The caveat of
course is that the user has to write this suffix somewhere, but that is
what makes the password strong anyway.
I don't think asking users to remember a password and a random value is
tenable.
And anyway, to be clear, this is just a discussion on an alternate design
that has the same properties and is significantly easier to implement for
both, authors and UAs, but it's by no means the only solution. My point is
that there are probably simpler solutions that have similar security
guarantees.
I'll reassert that this proposal is simpler for authors (11 character
opt-in) and users (no change) than the scheme you just outlined. It's more
complex for browser vendors, but that's fine and expected, as we're way
down at the bottom of the priority heap.
--
Mike West mk...@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.)
