Re: Credential Management

On Wed, May 20, 2015 at 1:48 PM, Mark Nottingham <mnot@mnot.net> wrote:
> [ I'm going to start inserting a standard disclaimer that I find gmail quoting conventions VERY annoying :) ]

[gmail loves you anyway (trying "plain text" mode, which is almost
100% guaranteed to be worse)]

> BTW, the spec refers to this for 'autocomplete':
>   http://www.w3.org/TR/html5/forms.html#attr-form-autocomplete
> when IMO this would be a much friendlier ref:
>   http://www.w3.org/TR/html5/forms.html#autofilling-form-controls:-the-autocomplete-attribute

An excellent point:
https://github.com/w3c/webappsec/commit/17f86325c34980cc624a48dfdb9cba0135a4ccc2

> > >  * Is the credential's name intended to correspond to the name that the user gives the credential in their manager, and is it available to the service?
> >
> > The `id` attribute on the credential has credential-specific meaning. In the case of `PasswordCredential` and `FederatedCredential`, the `id` is almost certainly the username.
>
> I was referring to the `name` attribute on LocallyStoredCredential.

Ah! Sorry. That's meant as something like a "friendly name" and is
provided by the site along with the credential. That is, I sign into
`amazing-social-network.example.com`, and it hands the browser a
credential like:

    { "id": "mkwst@google.com", "name": "Mike West", "password": "hunter2" }

There's no reason that couldn't be editable by the user via some
user-agent-provided mechanism, but the intention is that it's set to a
sane value by the site with whom you have a relationship.

> > CSP exists, and protects against these kinds of leakage. I don't see a good reason not to recommend it.
>
> I'm not saying we shouldn't recommend it; I'm wondering whether we can rely upon it.

Defense in depth, right?

If you have other recommendations, I'm happy to add them to the
document. CSP is a pretty decent defense against many forms of XSS.
The fact that it's hard to layer onto existing sites is an orthogonal
problem that we certainly ought to address, but I don't have good
ideas about what else we could use to plug that gap. If I did, I'd be
writing another spec. :)

> > More to the point, for same-origin requests, user mediation doesn't help. There's nothing a user agent can do to differentiate a "real" request from `bank.com` from an XSS'd request triggered by an attacker. The origin is the same, and if a user trusts `bank.com`, then they'll click the shiny button.
>
> *sigh* true. I'm concerned about attacks where the user doesn't even know that their password has been compromised - Navigate to the wrong link and it's all over. However, being same-origin does help.

Same-origin, and ignoring redirects. Both of those help, but are
certainly not foolproof. Again, I'd love to add more mitigation
recommendations.

Note, though, that this is generally an improvement over the status
quo, where an XSS can pop up a pretty-believable re-authentication
form on an origin which the user would type her password into. The API
in this document removes that vector, forcing a POST to a same-origin
endpoint, which means that the XSS would have to be combined with a
server-side vulnerability that dumped POST data back out to something
accessible to JS. Certainly possible, as
http://lcamtuf.coredump.cx/postxss/ shows, but a significantly higher
bar.

> > This was more of a concern when there was a "Hey, the login just failed!" notification in the API. Since we've removed that method in the meantime, it's probably a good idea to remove this section entirely.
>
> OK. If it stays, it might benefit from some editorial love.

I loved it so much it died:
https://github.com/w3c/webappsec/commit/2cd56a7287ab9dbd4b85398bb7f8fe77b671eb27

Thanks again!
--
Mike West <mkwst@google.com>, @mikewest

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 Wednesday, 20 May 2015 13:13:15 UTC