Path: utzoo!mnetor!uunet!husc6!rutgers!sdcsvax!ucbvax!CHPC.BRC.UTEXAS.EDU!sfmailer From: sfmailer@CHPC.BRC.UTEXAS.EDU ("Store and Forward Mailer") Newsgroups: comp.os.vms Subject: Re: USER ID PASS VALIDATION ON VMS Message-ID: <8712282209.AA07191@ucbvax.Berkeley.EDU> Date: 28 Dec 87 15:43:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: "Store and Forward Mailer" Organization: The ARPA Internet Lines: 71 Mail delivery failed to the following addresses: To: UTCSR::HASAN First attempt failed, will continue to retry for 3 days. %MAIL-E-LOGLINK, error creating network link to node UTCSR -SYSTEM-F-LINKEXIT, network partner exited ----------Returned Message Follows---------- From: MAILER Subject: [From: INFO-VAX@KL.SRI.COM] Re: USER ID PASS VALIDATION ON VMS Return-Path: <@KL.SRI.COM,@CUNYVM.CUNY.EDU:XRBEO@VPFVM.BITNET> Received: from KL.SRI.COM by chpc.brc.utexas.edu ; 28 Dec 87 09:37:44 CDT Received: from CUNYVM.CUNY.EDU by KL.SRI.COM with TCP; Mon 28 Dec 87 05:03:38-PST Received: from VPFVM.NSESCC.GSFC.NASA.GOV by CUNYVM.CUNY.EDU ; Mon, 28 Dec 87 08:03:51 EST Received: by VPFVM (Mailer X1.24) id 7877; Mon, 28 Dec 87 08:01:11 EST Resent-Date: Mon, 28 Dec 87 07:55:20 EST Resent-From: Bruce O'Neel Resent-To: INFO-VAX@KL.SRI.COM Received: from PSUVM.BITNET by VPFVM.NSESCC.GSFC.NASA.GOV (Mailer X1.24) with BSMTP id 5130; Thu, 24 Dec 87 06:37:43 EST Received: by PSUVM (Mailer X1.24) id 8640; Thu, 24 Dec 87 06:35:36 EST Date: Wed, 23 Dec 87 01:11:56 GMT Reply-To: INFO-VAX@KL.SRI.COM Sender: INFO-VAX Discussion Comments: Warning -- original Sender: tag was info-vax-request@kl.sri.com From: John M Boof Subject: Re: USER ID PASS VALIDATION ON VMS Comments: To: info-vax@kl.sri.com To: Bruce O'Neel ----------------------------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 ------