fennell@inco.UUCP (Tim Fennell) (12/15/87)
I need to find a VMS utility that will allow me to
validate a User ID and password. The application
I plan to use this is in a FTP server. The server
needs to validate a user's password and then
perform access control according to the new user's
or client's privileges. I can't find a SYS$ or LIB$
funtion that will help. If anybody knows of a way
please, help!!
Thanks ahead of time.
Tim Fennell
McDonnell Douglas/Inco Inc.fwb@siemens.UUCP (Frederic W. Brehm) (12/17/87)
In article <1288@inco.UUCP> fennell@inco.UUCP (Tim Fennell) writes: > > I need to find a VMS utility that will allow me to > validate a User ID and password. > ... I can't find a SYS$ or LIB$ > funtion that will help. If anybody knows of a way > please, help!! DEC has nothing in the libraries to help you. I had the same need and called DEC software support. Their response was "We do not support this, and never will, because it is a possible security loophole." The guy mentioned that some recent DECUS VAXSIG tape had some user software which would do the job. I did not follow this up because I don't want to support that software when DEC changes their encryption algorithm. If there is software for this on a SIG tape, perhaps some kind person can post it. Fred ---------------------------------------------------------------------------- Frederic W. Brehm Siemens Research and Technology Laboratories 105 College Road East Princeton, NJ 08540 (609) 734-3336 uucp: ihnp4!princeton!siemens!fwb or astrovax!siemens!fwb CSNet: fwb@siemens.com ARPA(?): fwb%siemens.com@RELAY.CS.NET "From there to here, from here to there, funny things are everywhere." - Dr. Seuss
art@MITRE.ARPA (Art McClinton) (12/17/87)
It is possible to use DECnet to open a logical link to a process using the
username and password. This can be done from within a program or from DCL.
The possible error messages that you can get for the link not being established
are: invalid username and invalid password. I think that this will totally
solve your problem. Obviously, if the link is established, then both
the account and password are valid. In this case drop the link and
continue. Note that this does require that the DECnet network be up
and running. It does not require a DECnet license to run DECnet on
your own machine, only do connect to other machines. DECnet has some
nice features that may make it useful to run it even if you are not
networked to anyt other machine.
This solution to password validation has been used before. The coding
excersice is trivial.
Stating that it is a security hole is a cop-out by the DECie that did not
know how to do it.
*
*---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 -=-=
In article <1288@inco.UUCP> fennell@inco.UUCP (Tim Fennell) writes:
>
> I need to find a VMS utility that will allow me to
> validate a User ID and password.
> ... I can't find a SYS$ or LIB$
> funtion that will help. If anybody knows of a way
> please, help!!
DEC has nothing in the libraries to help you. I had the same need and
called DEC software support. Their response was "We do not support this,
and never will, because it is a possible security loophole." The guy
mentioned that some recent DECUS VAXSIG tape had some user software which
would do the job. I did not follow this up because I don't want to support
that software when DEC changes their encryption algorithm.
If there is software for this on a SIG tape, perhaps some kind person can
post it.
Fred
----------------------------------------------------------------------------
Frederic W. Brehm Siemens Research and Technology Laboratories
105 College Road East Princeton, NJ 08540 (609) 734-3336
uucp: ihnp4!princeton!siemens!fwb or astrovax!siemens!fwb
CSNet: fwb@siemens.com ARPA(?): fwb%siemens.com@RELAY.CS.NET
"From there to here, from here to there, funny things are everywhere."
- Dr. Seussrrk@byuvax.bitnet (12/18/87)
The algorythm is in the microfische, but I don't remember exactly where.
sparacin@tilde.csc.ti.com (Keith Sparacin) (12/19/87)
>In article <1288@inco.UUCP> fennell@inco.UUCP (Tim Fennell) writes: >> >> I need to find a VMS utility that will allow me to >> validate a User ID and password. > >> ... I can't find a SYS$ or LIB$ >> funtion that will help. If anybody knows of a way >> please, help!! > I don't know about a VMS utility but there are calls you can make in VMS 4.7 (and earlier???) to validate a password. Use sys$getuai to get the UAF record for the username of interest. Use lgi$hpwd to hash your password and compare it with the UAF password. --------------------------------------------------------------- Keith Sparacin csnet: sparacin@ti-csl.csnet uucp: smu!ti-csl!sparacin arpanet: sparacin%ti-csl@relay.cs.net
mbr@beta.UUCP (Mike Rose) (12/19/87)
In article <1288@inco.UUCP> fennell@inco.UUCP (Tim Fennell) writes: >>> I need to find a VMS utility that will allow me to >>> validate a User ID and password. Someone, somewhere else writes >>Their [DEC] response was "We do not support this, >>and never will, because it is a possible security loophole." In article <8712171512.AA06909@mitre.arpa> art@MITRE.ARPA (Art McClinton) writes: >Stating that it is a security hole is a cop-out by the DECie that did not >know how to do it. I doubt that is the case. It is very easy to do, provided you leave a security hole. The routine HPWD.MAR in the fiche will hash a password, this can then be compared to the password(s) in the UAF with the $getuai system service. The security hole is that someone can then try lots of different passwords for a username without the intrusion detection system getting fired up or the attempts being logged. HPWD.MAR is documented, though poorly. (it has a 4 word description of each parameter required). I have routines that call it and check passwords, etc and will mail them to anyone. Unfortunately they are useless without the source code for HPWD.MAR, which I won't post because I don't know if it's legal to do so. There is no global entry point for LGI$HPWD. >It is possible to use DECnet to open a logical link to a process using the >username and password. Yes, it is possible. Starting up processes is a real cpu hog though. Also, if you are using usernames with two passwords only the first password is checked on network logins. The second is ignored. Mike Rose mbr@lanl.gov
IMHW400@INDYVAX.BITNET (12/20/87)
Mike Rose <BETA!MBR@HC.DSPO.GOV> writes: >I doubt that is the case. It is very easy to do, provided you leave >a security hole. The routine HPWD.MAR in the fiche will hash a >password, this can then be compared to the password(s) in the UAF >with the $getuai system service. The security hole is that someone >can then try lots of different passwords for a username without the >intrusion detection system getting fired up or the attempts being logged. > >HPWD.MAR is documented.... 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. It is not possible to defend a published algorithm by simply by making one realization of it hard to get at. Note that DEC could easily provide a system service to validate access information, that *would* trigger the intrusion detection system if necessary. It is difficult to conceive a legitimate use for such validation that would be harmed by such detection; most applications would do well to log such events. }flame on{ If DEC would implement logged validation, and *finish* the implementation of SETUAI (so that one could make *new* SYSUAF entries with properly hashed passwords, given sufficient privilege), then only crackers would have more than academic interest in this poor little routine, obviating further explanation. As it is, there must be hundreds of programmers trying to figure out how to use HPWD for their legitimate applications, which surely must increase our exposure to illegitimate uses. }flame off{ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Mark H. Wood (317)274-0749 Indiana University - Purdue University at Indianapolis 799 West Michigan Street, ET 1023 Indianapolis, IN 46202 USA [@disclaimer@]
mbr@beta.UUCP (Mike Rose) (12/22/87)
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. >Note that DEC could easily provide a system service to validate access >information, that *would* trigger the intrusion detection system if necessary. >It is difficult to conceive a legitimate use for such validation that would >be harmed by such detection; most applications would do well to log such >events. I agree. Mike Rose mbr@lanl.gov
jmb@beach.cis.ufl.edu (John M Boof) (12/23/87)
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. ...JMBoof _________________________ in order of preference: darpa-internet: VAX/VMS: boof%oak.decnet@pine.circa.ufl.edu or boof@pine.circa.ufl.edu uucp: Gould,UNIX: ... !ihnp4!codas!ufcsv!beach.cis.ufl.edu!jmb bitnet: VAX/VMS: boof@ufpine or boof@ifasgnv IBM CMS: $$$YEQ#@NERVM _________________________
jmb@BEACH.CIS.UFL.EDU (John M Boof) (12/23/87)
----------------------------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 <xrbeo@vpfvm> on bitnet
cfchiesa@bsu-cs.UUCP (Christopher F. Chiesa) (12/23/87)
In article <13592@beta.UUCP>, 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. > Oh, really? A college sophomore here at BSU sent me a mail message one day saying "run such-and-such program in my area..." - I ran it and was shown the binary string representing the hashed version of my password. It would be simplicity itself for that program to just happen to write said password, along with my username, into a log file. Anyone with access to the file could then run the program on their OWN area, reading their OWN password, play with their password until their bit-pattern matched MY bit-pattern, and have a valid password to use to log into my account. Sort of "reverse engineering," but there is some evidence lately (mysterious breakins to user accounts) that it works... And, incidentally, a file which could be written in that sophomore's directory, by his program run from MY username, would of necessity have RW access to my username; if he were to unleash this thing on the "public" (say, as an unannounced adjunct to a "public-access" program, of which there are probably hundreds here), that would imply W:RW access, meaning that soon there'd be a file full of passwords that EVERYONE could peek into at leisure. BIG security hole, if you ask me. Incidentally, I DID mean to say "A valid password..." above, rather than "THE..." -- this soph and I verified that I obtained the SAME bit-pattern from TWO slightly-different passwords, and that EITHER password would allow access to my account after using SET PASSWORD to set EITHER of them as my "real" password. Hole, hole, HOLE!!! Chris Chiesa ..!rutgers!iuvax!bsu-cs!cfchiesa
tihor@acf4.UUCP (Stephen Tihor) (12/24/87)
It is for this reason that the VMS passwords are salted from the username.
sommar@enea.UUCP (Erland Sommarskog) (12/28/87)
Christopher F. Chiesa (cfchiesa@bsu-cs.UUCP) writes: >Oh, really? A college sophomore here at BSU sent me a mail message one day >saying "run such-and-such program in my area..." - I ran it and was shown the >binary string representing the hashed version of my password. It would be >simplicity itself for that program to just happen to write said password, >along with my username, into a log file. Anyone with access to the file Since you don't seem to be more careful; wouldn't it just be easier to look over your shoulder when you type your username? User running programs they don't know of are a much bigger security hole than any official encryption algorithm. -- Erland Sommarskog ENEA Data, Stockholm sommar@enea.UUCP C, it's a 3rd class language, you can tell by the name.
sfmailer@CHPC.BRC.UTEXAS.EDU ("Store and Forward Mailer") (12/28/87)
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 <XRBEO%VPFVM.BITNET@CUNYVM.CUNY.EDU> 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 <INFO-VAX%VTVM2.BITNET@CUNYVM.CUNY.EDU> Comments: Warning -- original Sender: tag was info-vax-request@kl.sri.com From: John M Boof <beach.cis.ufl.edu!jmb@bikini.cis.ufl.edu> Subject: Re: USER ID PASS VALIDATION ON VMS Comments: To: info-vax@kl.sri.com To: Bruce O'Neel <XRBEO@VPFVM> ----------------------------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 <xrbeo@vpfvm> on bitnet ------
mbr@beta.UUCP (Mike Rose) (01/04/88)
In article <1740@bsu-cs.UUCP> cfchiesa@bsu-cs.UUCP (Christopher F. Chiesa) writes: >Oh, really? A college sophomore here at BSU sent me a mail message one day >saying "run such-and-such program in my area..." - I ran it and was shown the >binary string representing the hashed version of my password. Of course: the hashed password that you can get from $getuai is the password for the username running the program, not the password for the username that wrote the program. (btw, running a college sophomore's program without knowing exactly what it does is probably not a real good idea, unless done from a username with no privs, no files you aren't willing to have destroyed, etc. or unless you really trust the sophomore.) >Anyone with access to the file >could then run the program on their OWN area, reading their OWN password, >play with their password until their bit-pattern matched MY bit-pattern, >and have a valid password to use to log into my account. This won't work. Part of the hashed password is your username. Two usernames with the same password will have different hashed passwords. There is also a random number (the "salt") mashed in there. >if he were to unleash this thing on >the "public" (say, as an unannounced adjunct to a "public-access" program, >of which there are probably hundreds here), that would imply W:RW access, >meaning that soon there'd be a file full of passwords that EVERYONE could >peek into at leisure. BIG security hole, if you ask me. The "big security hole" is everyone running just any old "public-access program". I also think you exaggerate the ease of somehow inverting hashed passwords to give plaintext. The algorithm was designed to make this difficult. If you have some insight into how to do this or examples of it being done I'd like to hear them. >this soph and I verified that I obtained the SAME bit-pattern >from TWO slightly-different passwords, and that EITHER password would allow >access to my account after using SET PASSWORD to set EITHER of them as my >"real" password. Hole, hole, HOLE!!! I'm real curious about this. Would you send me details? -Mike Rose mbr@lanl.gov
mbr@beta.UUCP (Mike Rose) (01/04/88)
In article <9909@ufcsv.cis.ufl.EDU> jmb@beach.cis.ufl.edu (John M Boof) writes: >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. According to the system services reference manual that is only true if you have the privilege GRPPRV. I tested this under VMS 4.6 and it is implemented as described in the manual. Does everyone have GRPPRV on your VAXen? Mike Rose mbr@lanl.gov
kml@beach.cis.ufl.edu (Kevin M. Lahey) (01/07/88)
In article <13921@beta.UUCP> mbr@beta.UUCP (Mike Rose) writes: >In article <9909@ufcsv.cis.ufl.EDU> jmb@beach.cis.ufl.edu (John M Boof) writes: >>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. > >I tested this under VMS 4.6 and it is implemented as described ^^^ >in the manual. Does everyone have GRPPRV on your VAXen? > >Mike Rose >mbr@lanl.gov Try under version 4.5 before the emergency patch issued by DEC. It didn't behave the way the manuals claim -- thats why it was a BUG, not a feature :-) Now, does anybody have a reasonable explanation of how such an INCREDIBLE hole made it into the final release? I mean -- thats just the sorta new system service all the hacker types would just love to play with. Even better, why doesn't somebody explain why it is so horrible that we could get other people's names and hashed passwords -- you can do it on UNIX, an operating system which is a hell of a lot more secure than you folks seem to think. Cheers, Kevin -- -------------------------------------------------------------------------------- Kevin Lahey UUCP: ...ihnp4!codas!ufcsv!beach.cis.ufl.edu!kml University of Florida, CIS Internet: kml@beach.cis.ufl.edu
cfchiesa@bsu-cs.UUCP (Christopher F. Chiesa) (01/09/88)
In article <13920@beta.UUCP>, mbr@beta.UUCP (Mike Rose) writes: > In article <1740@bsu-cs.UUCP> cfchiesa@bsu-cs.UUCP (Christopher F. Chiesa) writes: > >Oh, really? A college sophomore here at BSU sent me a mail message one day > >saying "run such-and-such program in my area..." - I ran it and was shown the > >binary string representing the hashed version of my password. > > (btw, running a college sophomore's > program without knowing exactly what it does is probably not a real > good idea, unless done from a username with no privs, no files you > aren't willing to have destroyed, etc. or unless you really trust > the sophomore.) Nobody here, except the system manager(s), has any priv other than TMPMBX. I couldn't mess up any file but my own (or those of someone who's deliberately granting me access) even if I wanted to, which I don't. And it's SOP for stu- dents to consult with each other a la "How do I ..." and "here's how I..." matters, such as using system services (this kid and I are among only a hand- ful of people I'm aware of who even know what a system service IS...), so I trust him to a certain degree. > >this soph and I verified that I obtained the SAME bit-pattern > >from TWO slightly-different passwords, and that EITHER password would allow > >access to my account after using SET PASSWORD to set EITHER of them as my > >"real" password. Hole, hole, HOLE!!! > > I'm real curious about this. Would you send me details? I'll try, but first I'll have to rewrite the program the soph was using; he got rid of it due to fears (justified, I might add) that the system admini- strators might vent their wrath on him for daring to use $GETUAI ... Chris Chiesa Senior, CS Dept. Ball State University Muncie, IN