Re: Experimental implementation of SimpleMD5

When I posted the availability of an experimental implementation of
SimpleMD5 authentication I neglected to mention that I am running a
test version on my server.  Those of you implementing SimpleMD5 in
clients are welcome to test your clients at

with the sample username/password pair that is in the SimpleMD5
specification from Spyglass.

The source for my implementation is freely available for any use at

I might also take this opportunity to respond to the criticism of 
SimpleMD5 posted here by Phil Hallam-Baker.  As I understand it Phil's
criticisms are 

     1) SimpleMD5 is not as secure as SHTTP, and
     2) SimpleMD% is not a subset of SHTTP.

Both of these are quite true.  It is also true that SimpleMD5 is not
as secure as SSL and not compatibile with it.  But this really misses
the point of SimpleMD5.

In the fullness of time I hope and expect that security standards will
emerge for HTTP and that they will subsequently be implemented in most
browsers and servers.  However, in the meantime Basic authentication,
which transmits passwords essentially in the clear, is in widespread
use.  The point of the Spyglass proposal for SimpleMD5 is as a
stop-gap measure to replace Basic authentication.  It is nearly
identical to Basic authentication except that passwords are encrypted.
Of course security can be done better -- and presumably the security
working group is doing precisely that.  But in the meantime it is
definitely worth quickly replacing Basic authentication.

The changes required in the protocol are absolutely minimal.  There
need to be extra fields in one of the existing authentication header
lines from the server and one from the client.  Implementation for clients
should actually be easier than Basic authentication.  Implementation for
the server is not at all difficult.

One suggestion of Hallam-Baker I think is a very good one and I hope it
will be considered before the SimpleMD5 specification is finalized.
That is to authenticate the specific transaction rather than just all
transactions within a realm.  In practice this means requiring the client
to encrypt the URI requested along with the "nonce" and user password.
The added security is probably marginal but still worthwhile since it
is trivial to implement.

John Franks

Received on Monday, 23 January 1995 12:26:44 UTC