Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!mit-eddie!genrad!decvax!ucbvax!afwl-vax.UUCP!spear
From: spear@afwl-vax.UUCP.UUCP
Newsgroups: mod.computers.vax
Subject: Re: Password Verification via DECnet kludge
Message-ID: <8702172013.AA09740@ucbvax.Berkeley.EDU>
Date: Fri, 13-Feb-87 01:14:00 EST
Article-I.D.: ucbvax.8702172013.AA09740
Posted: Fri Feb 13 01:14:00 1987
Date-Received: Wed, 18-Feb-87 19:58:31 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: "SPEAR, JON" <spear@afwl-vax>
Organization: The ARPA Internet
Lines: 24
Approved: info-vax@sri-kl.arpa

While we are giving an earlier poster the keyboard lashing of his life (many
with bad info since $SET TERM/NOECHO, $INQUIRE no longer (as of VMS 4.4? 4.5?)
stores the response in the DCL recall buffer), let me mention yet another
problem or two with his scheme of using a DECnet file access (with access
control string) to verify a user's password. 

1) It's harder to keep the innards of the verification command procedure secret
since you can still enter 'F$VERIFY(1) at the $INQUIRE prompt and turn on
verify mode. Another reason to use $READ instead - you don't need a $SET
NOVERIFY after each one. 

2) If the user has an account on another system on the DECnet (perhaps he
carries around a MicroVAX-2000 disguised as a lunchbox), he might really be
using the UAF file on a remote machine over which you have no control. He need
only $DEFINE LOCAL_NODE_NAME REMOTE_NODE:: and/or $DEFINE 0 REMOTE_NODE:: and
the file access is rerouted. To fix this, see if F$TRNLNM("0") turns up
anything. 

Capt Jon L. Spear
AFWL/NTC, KAFB, NM 87117-6008

Disclaimer: This information is provided for comparison purposes only. Your
actual mileage may be different.
------