Re: potential security holes in digest authorization

Phillip M. Hallam-Baker (hallam@w3.org)
Wed, 26 Jul 95 13:27:28 -0400 

BASIC authentication is a serious security flaw and one which may comprom=
ise
the security of other systems. Many users use the same password on all th=
eir
accounts. Thus a scheme which sends a password en-clair may result in oth=
er
systems being compromised. There is a similar problem with MUDS, MOOS etc=
=2E

User education is not an acceptable =A8solution". 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 cl=
ear
authentication tokens. One can combine the schemes but the system is stil=
l
compromised if both the transport and authentication database is compromi=
sed.


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 tha=
t
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 secu=
rity
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 t=
o
permit multiple servers to share the same authentication data. What is mi=
ssing
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 t=
o
provide a password in such a way that the remote system need never know t=
he
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 securit=
y
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 h=
ours
and a central server distributes new authentication tokens to remote syst=
ems
(clints and servers) each day. This provides very kerberos like functiona=
lity.


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 woul=
d 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 argume=
nt 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 tha=
n by
the structure of the keying mode. A keyed digest is a function of two var=
iables
not one. There are simple modifications which could dramatically improve =
the
cryptographic power of the scheme, varying Ron's mysterious constants acc=
ording
to the key for example. This requires testeing etc so I prefer to leave i=
t to
the experts.


I do very strongly advise that people consider implementing this scheme a=
nd
consider the withdrawal of the BASIC scheme. Although backawrds compatibi=
lity
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 num=
ber of
compromises, we consider however that they are the appropriate compromise=
s 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 pas=
sword
digest function however to maintain database compatibility.

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

	   kdalgid=3D"<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!