httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brandon Long <>
Subject Re: Digest authentication q...
Date Mon, 05 Jun 1995 18:59:19 GMT
Last time, Robert S. Thau uttered the following other thing:
> A brief query on digest authentication...
> The digest authentication scheme basically works by having the client
> compute a cryptographic hash of the password, a server-supplied nonce
> value, and a bunch of other stuff.  The server then recomputes the
> correct value of the hash (by stringing together the same stuff that
> the client hashed, and running the same hash function), and bongs the
> client if its result doesn't match.  Of course, in order to do this,
> the server needs to know the user's password.  Simple, no?  No.
> The problem is that the .htpasswd files used by the current Basic
> authentication code do *not* contain the user's password, or
> information sufficient to reconstruct it; they just contain its
> one-way "crypt" hash.  This is done, I guess, to prevent compromise
> of a .htpasswd file from immediately compromising all access to the
> protected pages.
> However, with digest authentication, the server *does* need the
> passwords themselves, so if we are going to shield them from prying
> eyes, we need some other way to do it.  I see a few unpleasant
> alternatives:

The current implementation that we have uses MD5 to hash the password
into the file password file.  It doesn't use the same nonce, since
the nonce to pass is time dependent (to prohibit replay attacks).
I do think its too easy to figure out from the file, but its not
plaintext.  Perhaps we should use a server nonce (or per-directory),
but again, this just makes it harder, not impossible.

> 2) Shield the passwords by making the files mode '700', with trusted
>    owners; perform authentication checks with full root privilege,
>    before doing a setuid().
>    This would require us to insert a whole lot of code elsewhere to do
>    security checks which would otherwise be performed by the OS, so I
>    consider it a Very Bad Idea (CERN server to the contrary), but I
>    figured I'd mention it out of completeness.

Ouch, not to mention everyone who doesn't even like the parent process
running as root.

> 3) Use some real technology ;-).
>    The passwords are stored encrypted with a key known to the server
>    itself, and perhaps the htpasswd program (perhaps stored in a file
>    they can read at startup, but which is *not* readable by ordinary
>    mortals --- this becomes a little more palatable if the server
>    itself does the 'htpasswd' job, so no separate program needs access
>    to its key).

Somewhat similar to what I said before.  I wonder, could we do the MD5
on a crypted version?  Take the password as extracted from the MD5 auth,
and then crypt it and check vs. a crypted .htpasswd file.  This is
virtually the same as now, except that you replace MD5 with a time based
nonce for uuencode (A step up).  I'm not that clear about exactly how
MD5 works though.  Stan?
>    Aside from the administrative hassles, this approach faces one
>    *enormous* difficulty --- export control.

The obvious benefit of using crypt.  But, the problem is, the source
code is available.  Without using some key (which is in both the server
and the htpasswd program), its going to be a two way hash with the source
available.  Its a lot of code to somehow make the server capable of doing
the password file generation, but possible worth it (for the day when
you don't have to have an account on the server machine, just on the
server.  Remote publishing).

More thoughts.


 Brandon Long   (N9WUC)     "I think, therefore, I am confused." -- RAW
 Computer Engineering   	Run Linux '95.	It's that Easy. 
 University of Illinois
		Don't worry, these aren't even my views.

View raw message