Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cbatt!ucbvax!HAMLET.CALTECH.EDU!ken
From: ken@HAMLET.CALTECH.EDU.UUCP
Newsgroups: mod.computers.vax
Subject: Re: password checking command file
Message-ID: <870210202739.00h@Hamlet.Caltech.Edu>
Date: Tue, 10-Feb-87 23:27:39 EST
Article-I.D.: Hamlet.870210202739.00h
Posted: Tue Feb 10 23:27:39 1987
Date-Received: Thu, 12-Feb-87 02:02:25 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: Ken@Hamlet.Caltech.Edu (Kenneth Adelman)
Organization: The ARPA Internet
Lines: 29
Approved: info-vax@sri-kl.arpa

>$!  first we prompt for the username and password
>$ inquire name "Username"
>$ set terminal/noecho      !  don't echo password to screen
>$ inquire pwd "Password"
>$ set terminal/echo
>$ write sys$output "Validating your password... please wait"
>$!   now use DECNET to access a public directory that contains
> !   nothing that is secret... (our node happens to be "amy"
>$ dir/output=temp.tmp amy"''name' ''pwd'"::sys$sysdevice:[public]
>$ if .not. $status then goto reject

    Hee Hee Hee. As someone who 'used to work for the dark side' I
can assure you that this command file as presented has a more major
problem than INQUIRE stuffing the password into the RECALL buffer -

    Just hit <CR> twice and enter a blank username and password.
The DCL command line becomes:

$ dir/output=temp.tmp amy" "::sys$sysdevice:[public]

which will succeed if you have a default DECnet account.

    The idea looks sounds in principle, I think the problems lie
in the example.

                                            Kenneth Adelman
                                            Caltech
KEN@Hamlet.BITNET
KEN@Hamlet.Caltech.Edu