Re: potential security holes in digest authorization

BASIC authentication is a serious security flaw and one which may compromise
the security of other systems. Many users use the same password on all their
accounts. Thus a scheme which sends a password en-clair may result in other
systems being compromised. There is a similar problem with MUDS, MOOS etc.

User education is not an acceptable ¨solution". I simply don't want the
security of my system dependent on their competence.

Without public key being avaliable there is a choice, either the 
authentication system will involve sending messages en-clair which are
effectively authorisation tokens or there will be a stored database of clear
authentication tokens. One can combine the schemes but the system is still
compromised if both the transport and authentication database is compromised.


We thus took the decision based on the observation that the network is
easily compromised, files stored on machines less so. I do not accept that
Bill Moriss's argument concerning keeping password files in the clear
is or was ever a valid one, it is preferable to keep password files in
a form which prevents the access tokens from being deciphered. It is only
one secuirty concern and a minor one, sites which cannot protect the security
of their password file probably arn't interested in security. The main
justification I would give for one way encrypted password files would be to
protect the system from corrupt sysops.

MDA is not proposed as a replacement for or competitor for SSL/S-HTTP. It is
merely a simple scheme that provides the best protection we could provide at
low cost.


Concerning the tying of the username to the realm, this was a deliberate choice
on my part. If a user has the same username/password on multiple machines a
system manager at one site could obtain access to the other if there was
nothing to differentiate them. Its a realm name and not the server name to
permit multiple servers to share the same authentication data. What is missing
is the requirement that the realm name should be an INTERNIC reserved one, eg
we could use w3.org or blink.w3.org. I think this prevents collisions in the
desired manner.

Another reason for setting up the system in this way is to allow a user to
provide a password in such a way that the remote system need never know the
password. The authentication token is created in the client (eg forms i/f) and
sent to the other side. if this transmission is insecure the security is of
course compromised to an extent. It provides the user with better security
guaranies when dealing with buletin boards, MUDs etc.


Another consideration, the password database could be regularly refreshed via a
secure transport. Consider a situation where the realm changes every 24 hours
and a central server distributes new authentication tokens to remote systems
(clints and servers) each day. This provides very kerberos like functionality.


Concerning the nonce placement, I would prefer that additional schemes be
provided for rather than adjusting the default. This is because there is a
very substantial installed base of browsers with the draft scheme. I would also
sggest that we do *not* discuss a new MD5 based scheme. I believe that a very
much better scheme will shortly become avaliable. 

Moving the nonce to the end would not greatly impact security, the argument on
the nonce placement is mainly concerned with the function H ( k, m) where m is
the message. I deliberately specified H(k,H(m)) to ensure sealing of the
message and prevent possible extension attacks while ensuring that the
cryptographic distance of k, m to the result was comparable. I have since been
shown that there is a "question" as to whether I should have incorporated
padding or not. I suspect its not a problem since the MDA  authentication
packet cannot be extended in a simple manner.

I'm rather more concerned that this is not an appropriate use for MD5 than by
the structure of the keying mode. A keyed digest is a function of two variables
not one. There are simple modifications which could dramatically improve the
cryptographic power of the scheme, varying Ron's mysterious constants according
to the key for example. This requires testeing etc so I prefer to leave it to
the experts.


I do very strongly advise that people consider implementing this scheme and
consider the withdrawal of the BASIC scheme. Although backawrds compatibility
is a consideration it is one which in this case I would prefer to lose at the
earliest opportunity. We are aware that digest authentication makes a number of
compromises, we consider however that they are the appropriate compromises to
make.

I suggest that further development of the digest scheme consider adding a
keyed digest algorithm tag. It would be sensible to retain MD5 as the password
digest function however to maintain database compatibility.

Authorization: Digest
           username="<username>",             -- required
           realm="<realm>",                   -- required
           nonce="<nonce>",                   -- required
           uri="<requested-uri>",             -- required
           response="<digest>",               -- required
           message="<message-digest>",        -- OPTIONAL
           opaque="<opaque>"                  -- required if provided by server

	   kdalgid="<algid>"			-- OPTIONAL, default v1 scheme

-- 
Phillip M. Hallam-Baker            Not speaking for anoyone else
hallam@w3.org http://www.w3.org/hypertext/WWW/People/hallam.html
Information Superhighway -----> Hi-ho! Yow! I'm surfing Arpanet!

Received on Wednesday, 26 July 1995 10:30:21 UTC