W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 1998

RE: Some comments on Digest Auth

From: Dave Kristol <dmk@research.bell-labs.com>
Date: Tue, 20 Jan 98 17:18:09 EST
Message-Id: <9801202218.AA07589@aleatory.tempo.bell-labs.com>
To: paulle@microsoft.com
Cc: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/5232
Paul Leach <paulle@microsoft.com> wrote:
  > > [DMK]
  > > Let me say the same thing differently:  A replayable Digest is no worse
  > > than Basic.  And it has the merit that it eliminates cleartext passwords.
  > > 
  > A distinction without a difference. The fact that they are not plaintext is
  > irrelevant. The important property about plaintext is that it can be
  > replayed. If Digest can be replayed, then it has the property of plaintext
  > that we're trying to get rid of, and so we will have accomplished nothing.

To echo Ben Laurie's point:  the replay is good only for the object
already fetched (and, presumably, seen by the intruder), because the
URL is in the digest.  With Basic, the intruder could look at *any*
protected object by using the username/password.  Digest is stronger.
And, with suitable time-dependent nonce generation, the potential
damage is limited.

Maybe we should be stepping back to identify the kind of application
where we think Digest makes sense.  In my mind, Digest is meant for a
relatively simple application where the server wants to limit who can
look at some of the content, but that it wouldn't be TEOTWAWKI (the end
of the world as we know it) if someone actually saw the stuff.  If the
material were truly important, after all, we would be using SSL or
other encryption.

After all, if someone can sniff passwords, then they can also already
see the material flying by.  If they had a username/password under
Basic, then they could look at stuff at will.  So Digest merely limits
what an intruder can look at anyway, even with a tighter
specification.  It doesn't prevent the intruder from looking.

Dave Kristol
Received on Tuesday, 20 January 1998 14:22:52 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:04 UTC