httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From (Robert S. Thau)
Subject Re: Digest authentication q...
Date Mon, 05 Jun 1995 20:11:16 GMT
   Date: Mon, 5 Jun 1995 13:59:19 -0500 (CDT)
   From: Brandon Long <>
   X-Citement: Pontiac

X-Cessive customization: ... surely.

   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?

This cuts to the heart of the problem I was having, and perhaps som
confusion on my part as well.  If you *can* extract the password from
the MD5 information sent by the client, then you can use the same
technique as Rob M.'s old code uses to verify its authenticity without
having to store the password itself at all (to wit, the Unix
passwd-file trick).

However, I was very much under the impression that you can't, and that
the server has to have the cleartext of the password available to
duplicate the one-way MD5 "digestion" of password and nonce done by
the client and verify the result.  (In fact, this is to a great extent
the whole point of digest authentication --- the information which
travels over the wire either way is insufficient to allow a third
party with a packet sniffer to spoof access).

That doesn't mean that the password has to be stored in straight
plaintext on the server, but it does have to be stored in a form (I
think I called it ASCII armor) from which the actual plaintext can be
recovered.  And while I can imagine all sorts of elaborate forms of
such ASCII-armor, possibly including MD5, they don't fundamentally buy
you much, because everyone and his cat has the server source code,
from which they can conveniently extract the code needed to strip the
armor off and get at the bits.

(This does require a certain degree of technical sophistication, but
the degree of sophistication in the underground is substantial.  A
common tactic seen on cracked systems around here is the use of "root
kits", which replace certain common binaries with trojan-horse
versions that have identical lengths and checksums, and unaltered
last-modified dates from whatever was there previously.  Some of the
targets are what you'd expect (rlogind, etc.), but they also sometimes
include hacked versions of 'ls', 'du' and 'df' which conceal the files
and disk space usage of the crackers' capture files.  None of this
represents any kind of fundamental breakthrough in computer science,
but it does represent a hell of a lot of work on the part of some
fairly competent, and frighteningly antisocial, people).


View raw message