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.