Path: utzoo!mnetor!uunet!husc6!rutgers!ames!ucbcad!ucbvax!BEACH.CIS.UFL.EDU!jmb From: jmb@BEACH.CIS.UFL.EDU (John M Boof) Newsgroups: comp.os.vms Subject: Re: USER ID PASS VALIDATION ON VMS Message-ID: <8712281546.AA02147@ucbvax.Berkeley.EDU> Date: 23 Dec 87 01:11:56 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: INFO-VAX@KL.SRI.COM Organization: The ARPA Internet Lines: 39 ----------------------------Original message---------------------------- In the above-referenced article, mbr@beta.UUCP (Mike Rose) writes: >In article <8712192213.AA27374@ucbvax.Berkeley.EDU> IMHW400@INDYVAX.BITNET writes: >>May I point out that, if HPWD is documented then the security hole is already >>there. Anybody with access to the 'fiche can just recode it. > >That is not true. The hole is only there when you can somehow inquire >if a password is correct for a particular username. A non-privileged >user recoding the algorithm has nothing, since they cannot obtain the >hashed version of the correct password from the uaf. Ah, but GETUAI will give the hashed password and all UAF information for any user in your Group ID (UIC) - at least on the VAXes I have used. This caused quite a scare for some, since there are many devious-minded users on our main VAX. It has been taken care of on this one cluster, but other VAXes I use will still let you get that info. ------------------------------- End of forwarded mesage -------------- According to manual 8D, system service reference manual, page SYS-291, $GETUAI uses the following table to determine the nessary privs. -> BYPASS or SYSPRV -- allows access to any record in the UAF -> GRPPRV -- Allows access to any record in the UAF whose UIC group matches that of the requestor -> No privilege -- allows access only to record with uic matching that of the requestor. So... Becarefull with privs. And I admit, dec sure didn't point this one out Bruce on bitnet