Path: utzoo!mnetor!uunet!husc6!hao!ames!ucbcad!ucbvax!CITHEX.CALTECH.EDU!carl
From: carl@CITHEX.CALTECH.EDU (Carl J Lydick)
Newsgroups: comp.os.vms
Subject: Re:  Security problem in DQS
Message-ID: <871209023309.01h@CitHex.Caltech.Edu>
Date: 9 Dec 87 10:41:46 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 26


 > It should do no harm to simply delete the offending file after it has been
 > executed once, instead of doing it at SYSTARTUP time.  Since it does a DEFINE,
 > the password will be in the permanent DECnet database and need never be set
 > again, unless one wishes to change it.  I can't help feeling that the person
 > who wrote the DQS startup procedure has no previous experience with DECnet
 > management.  (*sigh*)

Good point.

 > This *does* mean that the password is *still* stored in a file, but we can
 > hope that DECnet uses the system password encryption routine to hash it
 > (as LOGINOUT, AUTHORIZE, and SET PASSWORD do).  Are you listening, DEC?

From the way you phrase this, I conclude that you ARE aware of the fact
that the password is stored in the clear (though the installation procedure
for VMS [or for DECnet, if you're on a uVAX] protects the file against reading
by world).  Unfortunately, the way things seem to work is that DECnet takes
the password given it (from the default DECnet account [privileged or
non-privileged, as appropriate], or from the definition of the object in
question, or from an ACE), hashes it, then compares it to what's in SYSUAF.
If my impression as to how DECnet handles access attempts from remote machines
is correct, then the password MUST be stored in the clear.  One remedy would,
of course, be to hash the password twice in normal usage before the compare,
but have DECnet hash it once before storing it in a file, then hash it the
second time before it makes its own comparison.