- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 31 May 2012 16:36:51 +0200
- To: Alexey Melnikov <alexey.melnikov@isode.com>
- CC: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
On 2012-05-31 16:15, Alexey Melnikov wrote: > On 31/05/2012 13:09, Mark Nottingham wrote: >> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/348> >> >> Proposal - >> >> New section in p7 Security Considerations: >> >> """ >> 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. >> """ > Mark, I might be missing something: I thought realm can be used to > restrict access to resources within a server (i.e. the same host can > serve multiple different realms, each realm can have its own user > password database). Your text above contradicts that. Yes, but the realm value doesn't tell the client what part of the URI space the credentials are for. So if you basic-authenticate to http://example.com/a successfully, the client may send the same credentials to http:://example.com/b, although it's a separate protection space. Best regards, Julian
Received on Thursday, 31 May 2012 14:37:25 UTC