- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Sat, 02 Jun 2012 12:18:09 +0200
- To: Martin Thomson <martin.thomson@gmail.com>
- CC: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
On 2012-05-31 18:11, Martin Thomson wrote: > On 31 May 2012 05:09, Mark Nottingham<mnot@mnot.net> wrote: >> 6.2 Protection Spaces >> >> Authentication schemes that use the "realm" mechanism for establishing a protection space will expose credentials to all resources on a server. This makes it possible for a resource to harvest authentication credentials for other resources on the same server. >> >> This is of particular concern when a servers hosts resources for multiple parties. Possible mitigation strategies include restricting direct access to authentication credentials (i.e., not making the content of the Authorization request header available), and separating protection spaces by using a different hostname for each party. > > Thanks. That addresses my concern. > > Though it would seem that the problem isn't well understood. Maybe > insert a bit more exposition... > > """[...] will expose credentials to all resources on a server. Clients > that have successfully made authenticated requests with a resource can > use the same authentication credentials for all resources on the same > server. This makes it possible for a [...]""" Thanks, Martin. I slightly tuned all of this to: > 6.2. Protection Spaces > > Authentication schemes that use the "realm" mechanism for > establishing a protection space will expose credentials to all > resources on a server. Clients that have successfully made > authenticated requests with a resource can use the same > authentication credentials for other resources on the same server. > This makes it possible for a different resource to harvest > authentication credentials for other resources. > > This is of particular concern when a server hosts resources for > multiple parties. Possible mitigation strategies include restricting > direct access to authentication credentials (i.e., not making the > content of the Authorization request header field available), and > separating protection spaces by using a different host name for each > party. (<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/348/348.diff>) Feedback appreciated, Julian
Received on Saturday, 2 June 2012 10:18:40 UTC