GEOFFRIL@UNION.BITNET.UUCP (02/09/87)
As the person who caused much of the recent debate over publishing the password encryption routine, I though you might like to see a very simple solution to the need for password verification. In my original problem, I had a privileged command that I wanted to protect further by asking the user to reenter his/her password. This would prevent someone else running the program by stepping up to the terminal while the proper user is away from the desk. this is a consideration when we develop programs for our student consultants who often need to step away from their station to help a user in distress. Our consultants are not very security conscious and ignore instructions not to leave a privileged terminal unattended. One of the INFO-VAX respondents suggested that we use DECnet instead of wasting time writing a procedure call. The following piece of DCL works fine and does not require publishing anything about the encryption formulas. It also logs bad passwords as logfails inthe accounting files, making it possible to trace breakin attempts. $! 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 Later in your code, you can delete the file temp.tmp This procedure is a bit slow since DECnet has to go out on the net anc back in, but it sure is simple. We find it adequate for programs that are not frequently used... In conjunction with ACL protection, it makes for a very tight procedure. Leo Geoffrion, Skidmore college GEOFFRIL@UNION.BITNET
carl@CITHEX.CALTECH.EDU.UUCP (02/10/87)
In-Reply-To: Your message dated 9-Feb-1987
To: GEOFFRIL%UNION.BITNET@wiscvm.wisc.edu, @CitHex.Caltech.Edu,
info-vax@CitHex.Caltech.Edu
In place of your procedure, which went:
$! 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
I'd suggest something of the form:
$ set noon !avoid abnormal exit
$ control = f$environment("CONTROL")
$ set nocontrol_y !and don't let the user abort the procedure
$! first we prompt for the username and password using read instead
$! of inquire so that the password isn't in the recall buffer
$ read/prompt="Username: " sys$command name
$ set terminal/noecho ! don't echo password to screen
$ read/prompt="Password: " sys$command pwd
$ set terminal/echo
$ write sys$output "Validating your password... please wait"
$! now use DECNET to create a file on the null device - no cleanup
$! is required this way
$ create sys$node"''name' ''pwd'"::nl:
$ status = $status
$ delete/symbol pwd ! get rid of the password fast
$ delete/symbol name
$ set control=('control') ! restore control-y if appropriate
$ if .not. status then goto reject
The reasons for my recommended changes:
1) INQUIRE stores whatever gets typed in the recall buffer (DEC
has indicated willingness to make it easy to flush the recall
buffer in a future release of VMS). This means that a few
control-B's will show the password that was used. READ doesn't
place the result in the recall buffer.
2) Since the symbols pwd and name are accessible if the user interrupts
out of the procedure, you must disable control-y until you've
deleted the pwd symbol. It's nice to restore it when you're done,
though; hence the use of F$ENVIRONMENT to determine the original
setting.
3) Use of the logical name SYS$NODE makes the procedure more portable;
in fact, it can be used from any machine on your DECnet without
making additional copies.
4) If you create a file on the null device, there's no cleanup
necessary; also, it doesn't require that any directories exist,
and is thus more portable.
This procedure is considerably tighter than the one you are currently using;
however, I make no claims as to how tight it actually is in an absolute sense.
By the way, if the users of this program are as lax about privileged jobs
as you indicated, I highly recommend that you write some short timeouts
into whatever this code is supposed to protect, so that they can't abandon
the terminal in the middle of the privileged program. I still don't see
how this procedure can grant selective access to a privileged program.
What you seem to need to do is permit the program to be run only by a select
group of users, and then only via a network job. Thus, instead of creating
the file on the null device, you'd run the appropriate program (as a task).bruceb@sdcsvax.ucsd.edu@telesoft.UUCP (02/11/87)
> The following piece of DCL works fine and does not require publishing > anything about the encryption formulas. It also logs bad passwords > as logfails inthe accounting files, making it possible to trace > breakin attempts. > > $! first we prompt for the username and password > $ inquire name "Username" ^^^^^^^^^^^^ bad news (and worse for 'inquire pwd' in original posting!) > In conjunction with ACL protection, it makes for > a very tight procedure. > > Leo Geoffrion, Skidmore college > GEOFFRIL@UNION.BITNET > While your basic idea is okay, you have placed one grevious fault in your DCL file! INQUIRE <symbol> places the user's answer in the command line recall buffer. If the user were to run your COM file as you have it written, another knowledgeable user could just drop by and press the 'up arrow' key a couple of times to find the password! Use READ rather than INQUIRE. INQUIRE is massively unsafe for this type of use. READ will not leave it around to be picked up. Please. bruce
dww@seismo.CSS.GOV@stl.stc.co.uk (02/12/87)
Both the macro program and the procedure using DECnet recently posted with the above subject will no doubt allow a program to re-verify that the user is the same person as he/she who originally logged on. But the procedure outlined could introduce a more serious security weakness than it solves. I don't want to outline the method in detail publicly, but getting users to re-enter their passwords to a program is NOT a good idea. UNLESS the user has a DIFFERENT password from their account-password, in which case it is only that special password which is at risk. If you don't see why this is a weakness, mail me and I'll explain (if the return route works!!).