Re: more on Digest Auth

> At the time digest design was being discussed I argued for timestamps
> and hashing the IP address, but was overruled.  Nevertheless, I was
> satisfied since the protocol allows any implementation to add the
> features I want via the opaque string.  Other implementations can
> add additional safeguards like the ones above and they will interoperate
> with clients supporting the protocol.  I think this is a feature.

Perhaps I'm missing something obvious, but I don't think the opaque string buys
you anything in this regard. It is independent of the digest value and is
something that the client simply echoes back to the server so how could it add

> Someone on this thread mentioned a problem with clients reusing
> passwords and mentioned the need for more than username, password and
> nonce to be hashed for the response.  More *is* hashed.  The realm
> (which should contain the hostname) is also part of what gets hashed.

True enough, but the realm is intended to identify the information the
user is trying to access. It's axiomatically the same in different
requests for the same information, which means it doesn't help ward
off replay attacks at all.

> Thus the same password on different servers could only be a problem
> if two servers used the same realm (presumably one host would be
> claiming to be the other).

It isn't clear that the realm is server-unique. In fact the implication in the
draft is that the realm is "target unique", that is, the realm is intended to
tell the client what username and password to use to reach this particular
chunk of information. A strong case can be made for having a single realm
across multiple servers because of this.

> Nonces by the way are opaque integers.
> In my implementation they are modified random numbers.  Another
> implementation could use a hash of a secret key + whatever and
> convert the result to a large integer.  (I think integer in this
> context only means digit string).

This is exactly the sort of approach I've been advocating. The nonce value
is included in the digest, and as long as it doesn't repeat and future
values cannot be predicted replay and preplay attacks are going to
be ineffective.

> The reason it would be  rather difficult to change the protocol now
> is that it is already in widespread use.  It is in all the current
> versions of browsers from Microsoft and NCSA.

I for one don't see any need to change the protocol and have been arguing
against such changes, because if you use it properly it is quite strong -- at
least as strong as APOP.

> For better or worse the current draft leaves a lot up to the
> implentation.  It is possible to have an implementation that is not
> much more secure than Basic.  It is also possible to have an
> implementation that addresses all of the issues raised in this thread,
> plus some more.  The current protocol is not exactly the way I would
> have done it if all the decisions were up to me, but as everyone in
> this discussion is aware we sometimes have to make compromises.

Yes, and the same thing could be said about APOP -- the POP3 specification
is sorely lacking in implementation advice, making it possible for
a perfectly valid APOP implementation to be not significantly more
secure than passwords in the clear. I think an informational
document is in order here describing the characteristics of such
schemes and how implementations can make them more resistant to attack.


Received on Wednesday, 21 February 1996 12:27:52 UTC