GEOFFRIL@UNION.BITNET.UUCP (01/28/87)
I am interested in the inclusion of a module within my program which first asks a user to enter their password, passes that program through the standard VMS one-way encryption formula and then compares it with the password stored in SYSUAF.DAT. In this way, I can assure that the authorized user is actually at the terminal when the command is entered (just as VMS SET PASSWORD required that you know your old password). Does anyone know of a high-level (e.g. non-macro) system call to VMS that accomplishes this}i feat?
art@mitre.ARPA.UUCP (01/30/87)
It would be possible to use the remote DECnet loggin facility to allow a
program to collect the password, pick up the current user name, and
then attempt to loggin remotely thru DECnet to allow LOGINOUT to
verify the usename and password. The result will be establishment of
a logical link if the password is valid and failure to establish the
link if the password is bad. Details left to the reader. I know of
systems using it where they validate to a remote user authorization
file. I do not see why they would not also work to a local UAF. I do
not know if you will need the DECnet key to do this.
Major advantage is it will work across all current and future versions
of VMS, does not require a separate file from the UAF. Major
disadvantage is that the validation will probably take 1-2 seconds
and will create another process in the computer.
*
*---Art
*
*Arthur T. McClinton Jr. ARPA: ART@MITRE.ARPA
*Mitre Corporation MS-Z305 Phone: 703-883-6356
*1820 Dolley Madison Blvd Internal Mitre: ART@MWVMS or M10319@MWVM
*McLean, Va. 22102 DECUS DCS: MCCLINTON
*
=-=- This note is in response to yours which follows -=-=
I am interested in the inclusion of a module within my program
which first asks a user to enter their password, passes that
program through the standard VMS one-way encryption formula and
then compares it with the password stored in SYSUAF.DAT.
In this way, I can assure that the authorized user is actually at
the terminal when the command is entered (just as VMS SET PASSWORD
required that you know your old password).
Does anyone know of a high-level (e.g. non-macro) system call
to VMS that accomplishes this}i feat?tencati@JPL-VLSI.ARPA.UUCP (02/02/87)
Please be careful about publishing code that encrypts passwords using the same formula DEC uses... These code fragments can fall into the hands of hackers who can then build "password-guessers" that will get around VMS security since there is now no way to catch "logfails". I know the module in and of itself is useful, but this list is *widely* read, and I think a little caution should be exercised in the distribution of such software. Ron Tencati System Mgr, JPL-VLSI.ARPA Jet Propulsion Laboratory 4800 Oak Grove Drive Pasadena, Ca. 91109
robert@jimi.cs.unlv.edu.UUCP (02/06/87)
>Please be careful about publishing code that encrypts passwords >using the same formula DEC uses... These code fragments can fall into >the hands of hackers who can then build "password-guessers" that will >get around VMS security since there is now no way to catch "logfails". Guessing passwords is only a useful approach if users choose passwords which are easy to guess. If you are concerned about security, you should choose passwords which are not likely to be contained in a dictionary. Keeping password algorithms under lock & key, and then choosing "dog" as a password is quite inconsistent. If you choose a password with letters & numbers, which is not a word, dictionary searches will always fail. Being able to verify a password is useful for those applications which need to be sure that the user at the terminal is the actual user, not someone who walked up to a terminal while someone was out to lunch. In any case, many sites have microfiche, including sites who employ hackers. For this reason, encryption algorithms should not rely on whether or not the algorithm is known to a perpetrator. If you do not trust your users to choose reasonable passwords, set the automatic password generation flag for them in sysuaf. --robert -- CSNET: robert%jimi.cs.unlv.edu@relay.cs.net UUCP: {sdcrdcf,ihnp4}!otto!jimi!robert seismo!unrvax!tahoe!jimi!robert
btb%ncoast.UUCP%case.CSNET@RELAY.CS.NET.UUCP (02/08/87)
sorry, I haven't been following the discussion, but what is all of this concern about VMS and security? I have been working on a VMS system for about a year now (we are up to 4.4), and it is one of the most secure systems I have ever (or ever hope to) work on... you can watch logfails, and you can set accounts & terminals up to shut down if there are more than so many logfails in a row... as far as file security goes, if you don't give anybody god-like privileges (like bypass, or setprv), you can protect all of the system files very well with set prot=(w:re,g:re)... all of the other comments also apply... password accounts are only as secure as the person managing the password... don't leave privileged accounts logged on to unsupervised terminals, etc. -- Brad Banko ...!decvax!cwruecmp!ncoast!btb Cleveland, Ohio "The only thing we have to fear on this planet is man." -- Carl Jung, 1875-1961
oberman%icaen.DECnet@LLL-ICDC.ARPA.UUCP (02/10/87)
>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. This procedure has a serious problem. The INQUIRE command leaves the password in the DCL recall buffer. Any time security is important, such as when a password is being entered, use a READ/PROMPT command. In fact, because of limitations in the INQUIRE command I routinely use the READ/PROMPT command in all command procedures. R. Kevin Oberman LLNL arpa: oberman@lll-icdc.arpa (415) 422-6955 ------