I tested this particular problem with Internet Explorer 4.72.3110.8 (IE4) and
5.00.2314.1003 (IE5) by sending an authentication header of "WWW-Authenticate:
Ralph Realm" (the nonexistent "Ralph" authentication scheme) and both performed
exactly as Arne suggested they should. Both clients displayed the entity (HTML
document) sent with the 401 Unauthorized response header. This behavior is
expected if the user cannot supply valid credentials for the requested resource.
Clearly, because the user agent (browser) doesn't understand the supplied
authentication schemes, the user is unable to supply valid credentials.
In RFC 2617, "HTTP Authentication: Basic and Digest Access Authentication",
the following behavior is defined:
..."The user agent MUST
choose to use one of the challenges with the strongest auth-scheme it
understands and request credentials from the user based upon that
challenge."...
IMHO, this says that the user agent should not attempt authentication unless
it understands at least one of the supplied authentication schemes.
I don't think the behavior exhibited by Netscape is really a security hole
(not that Arne said it was). Malicious web sites could just as easily send a
"Basic" authentication header to users to obtain a username/password and then
attempt to use it against the machine or network that originated the request.
The only circumstance that I can see where this would be a security issue is
when the user is told by a trusted party (network administrator) to visit web
site "x" and use their "NT" (or other normally secure) credentials. If the
trusted party forgets to mention that the user needs to use a specific browser
that understands the authentication method in use, and the user naively uses a
Netscape browser, the normally secure credentials are transmitted in cleartext
over the network.
I DO think that this bug in Netscape should be fixed. As RFC 2616, "Hypertext
Transfer Protocol -- HTTP/1.1", suggests:
The ..."entity might include relevant diagnostic information"...
Information that tells the user which browser is capable of supporting the
authentication scheme in use may be included in the body of the document.
Arne did not mention which versions of Netscape he tested so I went ahead and
tested this with Navigator 2.02, 3.04 and Communicator 4.5. All of them
performed exactly as Arne described.
Adam
Arne Vidstrom wrote:
>
> Hi all,
>
> Netscape Navigator takes a somewhat strange approach to HTTP access
> authentication. Say for example that you use IIS 4 as a web server, and
> configure it to allow only Windows NT Challenge/Response authentication.
> When Navigator connects to the server it receives (among other things) the
> header "WWW-Authenticate: NTLM", but *no* "WWW-Authenticate: Basic" header.
> In this case you would expect Navigator to pop up a message to the user
> with something like "Error: This browser doesn't support any authentication
> method supported by the server!". Instead, it pops up the "Username and
> Password Required" box. When the user fills it in and clicks OK, the
> username and password are sent in plaintext over the network to the server,
> which of course doesn't accept them. Even more strange I think, is that the
> HTTP/1.1 protocol (as far as I can tell from reading it, but I could have
> missed it) doesn't say anything about how a browser is supposed to handle a
> situation like this. Even though it mentions that other authentication
> methods than Basic should be used for better security. Of course when a
> server sends one or more supported authentication methods it ought to mean
> "I support these *only*, don't send me any others!", right? Also, the
> message which comes when the authentication above fails is "Authentication
> failed. Retry?" - this doesn't even give a hint about what's wrong - and
> the user will probably try again and again, thinking that he/she typed the
> password wrong. Each time sending the password in plaintext over the
> network.
>
> Regards,
>
> /Arne Vidstrom
