httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@ai.mit.edu (Robert S. Thau)
Subject Digest authentication q...
Date Mon, 05 Jun 1995 11:34:30 GMT
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:

1) Just put the passwords in the files in the clear, and hope.  We
   could consider adding some sort of ASCII-armoring to make things a
   *little* harder on the crackers, but I strongly suspect that this
   would only give foolish webmasters a false sense of security.
   
   (On the other hand, this isn't *so* much worse than the current
   sad state of affairs --- leak of a current-model .htpasswd file
   doesn't give anything away immediately, but you're pretty likely
   to come up with something by running a dictionary search).

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.

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).

   Aside from the administrative hassles, this approach faces one
   *enormous* difficulty --- export control.

Any thoughts?

rst

Mime
View raw message