W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1995

SimpleMD5 quibbles

From: Dave Kristol <dmk@allegra.att.com>
Date: Wed, 1 Feb 95 16:24:12 EST
Message-Id: <9502012133.AA08440@hplb.hpl.hp.com>
To: www-security@ns2.rutgers.edu, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Cc: eric@allegra.att.com, john@math.nwu.edu, jeff@spyglass.com
I have finally gotten to play with the SimpleMD5 spec. from Spyglass
and John Franks's toolkit.  I would like to offer these suggestions.

1) The password that gets MD5-ed by the client must be stored on the
server as plaintext, so the server can do MD5(nonce password).  I find
that to be a problem, since, at least in my environment, many of the
servers are on Unix machines with shared file systems, and it would be
relatively easy for someone to find another's password.  I would prefer
that the password be stored encoded by some function f() (possibly MD5?).
Then the client would compute MD5(nonce f(passwd)), and the server could
duplicate the computation, except it would have f(passwd) in its password
file already.

2) I've been annoyed in Basic authentication by the fact that what the
client and server call "realm" is also used as a prompt to the user.
Can we separate the two concepts in SimpleMD5 (and Basic, for that
matter) by having the client and server continue to exchange a "realm"
attribute and have the server pass a "prompt" attribute for the client
to use?  A server that didn't want to do so pass the same value for
"prompt" as for "realm".  A client that didn't see a "prompt" attribute
could use the value of "realm" as a default.

3) In the SimpleMD5 spec. (and Franks's program) there's an insistence
that values (e.g., "PrideRock" in realm="PrideRock") be "-delimited.
Seems to me this is only necessary when there's an embedded space or
TAB or comma.  How about if we tolerate a non-"-delimited span of
contiguous characters that has no embedded space, TAB, or comma.
(Are there other characters of which to beware too?)

Dave Kristol
Received on Wednesday, 1 February 1995 13:41:21 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:13 UTC