Re: SimpleMD5 quibbles

According to Dave Kristol:
> 
> 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.

This is a good idea, but it is important to understand that it doesn't
really protect you the way you might think.  It is still necessary to
protect the password file from being read by any untrusted user.  If
an untrusted user gets the encoded password f(passwd) he can create
MD5(nonce f(passwd)) and access everything the user with passwd is
entitled to.  The reason it is a good idea is that people foolishly
tend to use the same password on many systems so the sysadmin on the
SimpleMD5 system might read the password and guess that the user has
that password on a different system.

It would also be a very good idea to actually encrypt the password in
the password file and decrypt it when checking access.  This may
involve export problems though.  Here is a way one might do it using
only MD5 (which is exportable).  Have a KEY known only to the server
and password management utilities. In the password file store

	username:salt:encrypted_pw
where
	encrypted_pw :=	password xor MD5( username:salt:KEY)

then the server can extract password because it is equal to

	encrypted_pw xor MD5( username:salt:KEY)

The salt must change whenever the user changes password.  Someone
reading the password file cannot decrypt the password without knowing
KEY.  

I don't know how cryptographically sound this is but it should be good
enough for SimpleMD5.  I also am not certain that the fact that SimpleMD5
is exportable would make this exportable.

John Franks

Received on Wednesday, 1 February 1995 14:19:51 UTC