Path: utzoo!mnetor!uunet!husc6!rutgers!iuvax!bsu-cs!jdh From: jdh@bsu-cs.UUCP (John Hiday) Newsgroups: comp.os.vms Subject: Re: 'security holes' Message-ID: <1743@bsu-cs.UUCP> Date: 27 Dec 87 22:07:55 GMT References: <8712262324.AA10045@ucbvax.Berkeley.EDU> Reply-To: jdh@bsu-cs.UUCP (John Hiday) Organization: Ball State University UCS, Muncie, IN Lines: 60 In article <8712262324.AA10045@ucbvax.Berkeley.EDU> BORDEN@YALEMED.BITNET (jonathan) writes: }In article <1740@bsu-cs.UUCP> cfchiesa@bsu-cs.UUCP (Christopher F. Chiesa) writes: }} }} [load of bull about his hacking buddy's latest triumph deleted...] }} Sort of }}"reverse engineering," but there is some evidence lately (mysterious }}breakins to user accounts) that it works... [...] Are you confessing? :-) } 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 question then is: what is the }protection on the system files at that site? } The only password security problem at our site is one that is shared by most other sites in the world -- ignorant users. All recent breakin problems have been traced back to insanely easy passwords. No matter how much we preach/bitch about good passwords vs. bad passwords, it seems users never learn until they've been burned (three or four times). It would be nice if we could lock everyone into generated passwords, set their password minimum > 10 characters and expire passwords every 30 days, but with 18,000+ active user accounts on our VAXcluster (all faculty/staff/students can have an account just for the asking) we would need a full time staff of several people just to take care of forgotten, and/or screwed up passwords. Just having a user's hashed password value poses no threat if the user has picked an intelligent password. It would take mounds of CPU time to find it via the pick a word, hash it, compare hashed values method. Even though having the hashed value of a person's password doesn't give you a lot, it does give you more information that you could have gotten without $GETUAI. Ever since $GETUAI came out in V4.4 I have always wondered why DEC made it a non-privileged routine. I know that with privs you can only get info on yourself, but it does pose trojan horse problems. Up until about two months after we put up V4.4 we kept the user's university ID number in the OWNER field of their UAF record. All such info was removed from the UAF after we caught someone with a trojan horse inside one of their publicly accessible utilities which logged the username and university ID of each user who ran it. Before $GETUAI this was not a problem since there was no way that a non-privileged user could get at their UAF record. John Hiday Intergraph/VAXcluster systems programmer -- == John Hiday UUCP: !{iuvax,pur-ee,uunet}!bsu-cs!jdh == Ball State University / University Computing Services GEnie: JDHIDAY == Muncie, IN 47306