[371] in WWW Security List Archive
Re: SimpleMD5 quibbles
daemon@ATHENA.MIT.EDU (Phillip M. Hallam-Baker)
Thu Feb 2 12:14:03 1995
To: www-security@ns2.rutgers.edu
cc: hallam@dxal18.cern.ch
In-reply-to: Your message of "Wed, 01 Feb 1995 23:15:08 +0900."
<9502012215.AA05918@hopf.math.nwu.edu>
Date: Thu, 2 Feb 1995 05:44:34 +0900
From: "Phillip M. Hallam-Baker" <hallam@dxal18.cern.ch>
Reply-To: www-security@ns2.rutgers.edu
Errors-To: owner-www-security@ns2.rutgers.edu
>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 precisely the reason for using MD5(realm + username + password) in my
system now renamed "ComplexMd5". The nonce shouldn't come into it. That is in
the message authentication checksum MD5(Method + URI + time? + nonce? + key).
Reading the password file does reveal the key. The problem is though that the
requirement to have an opaque key becomes the following.
Devise a system in which a message M, may be signed by a key S and verified
with a key V such that S may not be deduced from V.
This requirement is clearly that alledgedly pattented under the Diffie
Helleman patent. Now this is not a problem as far as ITAR is concerned
provided we only do authentication. But is is a big problem on speed and on
acceptance. The basic scheme has to be avaliable and implementable anywhere
and by anyone.
For high security one would employ the shared secret system for actual
user transactions but employ a shared secret key that was distributed
via RSA each 24 hours (say).
Note that in the RSA system dicovery of the signature information is a major
problem too. This is one pragmatic reason why I like the idea of smartcards,
the private portion of the public key need never leave the card.
Note also that the lack of faith in the ability of the system to keey the
authentication information secret is in many ways a lack of faith in the
security of the system as a whole. If the system leaks password files then
it is almost certainly leaking every other sort of information one might
want to keep private. On such a mismanaged system the concern is to prevent
a compromise of that one site compromising other sites which my "ComplexMD5"
variant does.
This scheme in NOT intended to provide the same level of practical security as
the full Shen/SHTTP features on HTTP/2.0. It is meant to be a quick hack to bury
the Basic scheme ASAP while not producing a second scheme which may be
compromised at the algorithmic level.
As a rough guide :
ComplexMD5 > SimpleMd5
SimpleMD5 > Telnet, X11, rlogin, rsh
USELESS-UNIX > ComplexMd5
Where USELESS-UNIX is a UNIX machine which can only ever be logged into via the
console, has no network connection, no NFS filesystem etc etc. This is the
system of the UNIX "security" guide. The reason why the guide is so dangerously
misleading is that it fails to address the central question of a computer
security system, how to maintain security in a system that IS at risk in some
way. Taking one aspect of a system that has an impractical security scheme
and making it an absolute requirement for a practical security scheme is a
severe mistake.
We have three requirements :
1) Passwords must not be deducable from stored information
2) Analysis of messages must not reveal access information
3) Analysis of stored information must not reveal access information.
In a network requirements 1 and 2 are the absolute essential ones. 3 is a
very nice to have one but I cannot work out a method of satisfying it.
I have looked at the following:
1) S/Key
- rejected because it requires frequent updates of the
authentication information.
2) VeryComplexMD5
- Here we use two authentication keys, one formed from the message
as in ComplexMD5, a second hashed key that is constant for all
messages is used. To break this system it is necessary to both
analyse messages AND the password file. I didn't think this was
a worthwhile advance though.
3) Commutative hash
this is the one that falls into the digital signature problem.
All in all this is very :-(
Phill Hallam-Baker
------- End of Forwarded Message
