Path: utzoo!mnetor!uunet!husc6!rutgers!ucla-cs!zen!ucbvax!YALEMED.BITNET!BORDEN From: BORDEN@YALEMED.BITNET (jonathan) Newsgroups: comp.os.vms Subject: 'security holes' Message-ID: <8712262324.AA10045@ucbvax.Berkeley.EDU> Date: 26 Dec 87 21:44:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 61 In response to the following message: From: "Christopher F. Chiesa" Subject: Re: USER ID PASS VALIDATION ON VMS >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 The question is: given an arbitrary hashed password can you easily derive the origional? The fact is that *ANYONE* with access to the UAF can get all the hased passwords for all the users on the system ... this does not give you access to all the accounts however. So what if two similar passwords give the same hash code? This does not indicate that it is easy to obtain the origional password from a hashed code... the WHOLE POINT of selecting an adequate password encryption formula is to prevent anyone from obtaining the origional password from the encrypted code *EVEN THOUGH YOU HAVE THE ALGORITHM USED TO ENCRYPT THE PASSWORD* ... in fact Digital publishes the password encryption algorithm. The discussion on "file privileges" is confusing the protection associated with a file describes the access privs for other USERS/PROCESSES toward that file. Executable files may only have privs when installed. We would assume the sophmore has not managed to install the program. The question then is: what is the protection on the system files at that site? jon borden yale university borden @ yalemed