You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by dave madden <dh...@paradigm.webvision.com> on 1996/06/30 23:24:46 UTC

authentication

I wonder if anyone (besides me :-) has considered doing a challenge-
response authentication mechanism that's more secure than the Basic
auth.  Certainly, it would require a plug-in on the client side as
well as a server module, but it would eliminate the current traffic in
what are basically plaintext passwords without requiring SSL.  Here's
how it would work:

When the client requested a protected resource, the server would
respond with 401 Unauthorized, and a WWW-Authenticate: header
containing the name of the realm and a random number.  The client
would prompt the user for a password, concatenate the server's random
number with one of its own, encrypt the result, and send an
Authorization: header with its next request, containing its own random
number in the clear, and the encrypted result.  On each subsequent
request from the same realm, both sides would generate new random
numbers and the client would keep encrypting and returning the
server's numbers.  (The reason for the client contribution to the
challenge is to prevent nasty servers from choosing "random"
challenges that could compromise the client's key.)

Anyone interested in this sort of functionality?

regards,
d.



Re: authentication

Posted by Brian Behlendorf <br...@organic.com>.
That's a fairly close description of what Digest authentication does, as
implemented in apache by mod_digest and in a couple of the browsers out
there, unfortunately not Netscape yet.

I'm sure someone around here has a URL to reference for this too...
unfortunately the docs haven't been written for that module yet.

	Brian

On Sun, 30 Jun 1996, dave madden wrote:
> I wonder if anyone (besides me :-) has considered doing a challenge-
> response authentication mechanism that's more secure than the Basic
> auth.  Certainly, it would require a plug-in on the client side as
> well as a server module, but it would eliminate the current traffic in
> what are basically plaintext passwords without requiring SSL.  Here's
> how it would work:
> 
> When the client requested a protected resource, the server would
> respond with 401 Unauthorized, and a WWW-Authenticate: header
> containing the name of the realm and a random number.  The client
> would prompt the user for a password, concatenate the server's random
> number with one of its own, encrypt the result, and send an
> Authorization: header with its next request, containing its own random
> number in the clear, and the encrypted result.  On each subsequent
> request from the same realm, both sides would generate new random
> numbers and the client would keep encrypting and returning the
> server's numbers.  (The reason for the client contribution to the
> challenge is to prevent nasty servers from choosing "random"
> challenges that could compromise the client's key.)
> 
> Anyone interested in this sort of functionality?
> 
> regards,
> d.
> 
> 
> 
> 

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com  www.apache.org  hyperreal.com  http://www.organic.com/JOBS