BORDEN@YALEMED.BITNET (jonathan) (12/27/87)
In response to the following message: From: "Christopher F. Chiesa" <BSU-CS!CFCHIESA@IUVAX.CS.INDIANA.EDU> 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
jdh@bsu-cs.UUCP (John Hiday) (12/28/87)
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: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!jdh == Ball State University / University Computing Services GEnie: JDHIDAY == Muncie, IN 47306
JOE@FHCRCVAX.BITNET (Joe Meadows) (12/29/87)
> 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. A few years ago, I wrote a program to go through the UAF and find all users who had a specific password (seems a lot of universities give all their new accounts the same password). It would have been trivial to add a dictionary and search through each username against every word in the dictionary. While not fast, a majority of passwords would indeed be found out this way. This is one reason why DEC added SET PASSWORD/GENERATE option and the flag in the UAF for forcing a user to use generated passwords. I tried other popular passwords with the above program and found several privileged accounts. Since I could easily obtain all the privilege I ever wanted (this was under VMS V3.n) I never bothered used any of this info, however, I offered the program to the system administrators so they would be aware of the possible hole. They also used it to scold people who hadn't changed their password (or changed it back). Of course, if you can't get the info out of the authorization file then you're going to have a harder time with it. However, a lot of people write PD software with just such traps as described before, writing out the current users hashed password into a file.. Luckily, not all hackers have easy access to the micro-fiche, sadly some of the hackers on the evil side of the force do... Cheers, Joe Meadows joe@fhcrcvax.bitnet
cfchiesa@bsu-cs.UUCP (Christopher F. Chiesa) (12/29/87)
In article <1743@bsu-cs.UUCP>, jdh@bsu-cs.UUCP (John Hiday) writes: > 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...] ^^^^^^^^^^^^ Oh, really? Do you mean to imply that I was inflating the tale? I assure you, the entire episode occurred exactly as related... > }} Sort of > }}"reverse engineering," but there is some evidence lately (mysterious > }}breakins to user accounts) that it works... [...] > > Are you confessing? :-) No, just keeping you (seeing as how you're one of our system admin'ers!) informed as to the things that get discussed in the public terminal rooms on occasion... :-) > > } The question is: given an arbitrary hashed password can you easily > }derive the origional? No. But the point is, you don't HAVE to derive THE original password - just any ONE of the (numerous) combinations that happens to hash out to the same encryption result as the original password... > } [Stuff deleted...] > 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. ... so you mean to tell me that the only thing keeping our passwords safe are a) the ethics of student hackers NOT to write a "pick word, hash it, compare hashed values" program, and b) CPU time limits and statistical reas- surance that the job will take too long to be useful to the hacker ? Sounds to me like someone is overestimating the ethics, and underestimating the persistence, of some of the minds "out there"... not that they're necessarily "evil," but password-finding could be considered quite a "challenge!" > 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. Exactly! It seems to be enough, coupled with other available VMS opera- tions, to get a real big start on the password-finding process. > 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,... I think you mean "WITHOUT privs...," John... > ... but it does pose trojan horse > problems. Darn right. A program can pull UAF data for whatever UIC happens to EXECUTE it, NOT just the one that OWNS it. > [...other stuff deleted...] Chris Chiesa CS Student Ball State University, Muncie, Indiana ..!rutgers!iuvax!bsu-cs!cfchiesa
LEICHTER@VENUS.YCC.YALE.EDU ("Jerry Leichter ", LEICHTER-JERRY@CS.YALE.EDU) (12/30/87)
All right, enough is enough: > > } The question is: given an arbitrary hashed password can you > }easily derive the origional? No. But the point is, you don't HAVE to derive THE original password, just any ONE of the (numerous) combinations that happens to hash out to the same encryption result as the original password... > } [Stuff deleted...] > 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. ... so you mean to tell me that the only thing keeping our passwords safe are a) the ethics of student hackers NOT to write a "pick word, hash it, compare hashed values" program, and b) CPU time limits and statistical reassurance that the job will take too long to be useful to the hacker ? Sounds to me like someone is overestimating the ethics, and underestimating the persistence, of some of the minds "out there"... not that they're necessarily "evil," but password-finding could be considered quite a "challenge!" All this general speculation is fine, but have you ever actually sat down and worked out the numbers? It's quite true that getting the original password back is not necessary (in fact, it's theoretically impossible); so, assuming the encryption is any good - and there's good reason to believe that - picking random passwords and hashing them produces essentially random hashed password values. Hence, to determine how long it will take to find ANY password that hashes to a value you read with $GETUAI, you need only calculate the expected time to GUESS a random hashed password. How many such are there? 2^64. A quick approximation gives 2^64 = (2^10)^6.4 ~= (10 ^ 3) ^ 6.4 ~= 10^19. Suppose you wrote some really fast code and could check a password a micro- second. There are 60 * 60 * 24 * 365 = 31536000 ~= 3*10^7 seconds/year, or about 3 * 10^13 microseconds. Hence, your expected time to find a password is 10^19 / 2 * 3 * 10^13 ~= 10^5 years. Frankly, I'm not worried. This is a large enough value that you can even posit a lot more technology. For example, if you could test a password a nanosecond - way beyond anything we could build today - you would still have an expected time of 100 years. Alternatively, if you had a Connection Machine, with about 10^5 processors, each using a microsecond per password, you'd still be talking a year of expected time. And note that I've been quite conservative in my calculations of times, and quite generous in my estimates of processor speeds; a more exact calculation would probably add two more factors of 10 to the time estimate. (Of course, there MIGHT be an algorithm for inverting hashed password quickly. It's not likely, but it could be the case. On the other hand, passwords, in the clear, move over terminal lines and Ethernets every day....) BTW, pre-computing a table of hashed values of, say, all the words in a big dictionary doesn't help - that's exactly why the "salt" value is there. If you and I have different "salt" values - and we are almost certain to - then even if we choose the same password, we get different hashed passwords. Further, even if our hashed passwords happen to agree, I still can't use my password to log in to your account. (If you don't understand how this works, see the classic paper on security in the collection of Unix papers from AT&T.) > 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. Exactly! It seems to be enough, coupled with other available VMS operations, to get a real big start on the password-finding process. A meaningless advantage, in light of the calculations given above. It would be much easier to bribe someone with a privileged account, or tap a phone line, or pick the locks on the computer room door. > 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,... I think you mean "WITHOUT privs...," John... > ... but it does pose trojan horse > problems. Darn right. A program can pull UAF data for whatever UIC happens to EXECUTE it, NOT just the one that OWNS it. I can do a lot more damage to you with a Trojan horse program than stealing your hashed password! In any case, it's important to keep a couple of things in mind: - ALL security is "statistical". Locks can be picked. "Failsafe" hardware will eventually fail - one of these days, a user program on a VAX will suddenly, due to cosmic rays, find itself running in kernel mode. - Security is not an absolute thing; it's essentially a ratio of cost and benefit: X is secure if the cost of obtaining X is greater than its value. There's no point in making one particular way of obtaining X extremely expensive while leaving others cheap - e.g., there's no point in putting a heavy, expensive, unpickable lock on a glass door. - Every security measure has its costs and its benefits. $GETUAI is available to non-privileged users for their own accounts because the information can be very useful to have. In any case, it in some sense BELONGS to the account owner - why SHOULDN'T he be able to get at it? (It's worth noting, BTW, that prior to V4.0, the SYSUAF's default protection allowed anyone to read it. On Unix systems, the passwd file, which contains everyone's hashed password, is also set up to allow everyone to read it - in fact, a lot of programs rely on that.) -- Jerry
gregg@a.cs.okstate.edu (Gregg Wonderly) (01/05/88)
in article <8712292021.AA24296@ucbvax.Berkeley.EDU>, LEICHTER@VENUS.YCC.YALE.EDU ("Jerry Leichter ", LEICHTER-JERRY@CS.YALE.EDU) says: > > [Some calculations about times to find passwords] > But, more importantly are the lengths of passwords, and the general character set that they are composed of. Typically, it takes ~96 guesses to discover if a users password is 1 character. 96^2 for 2 letter passwords, and so on. From this, you get the following numbers 96^1 = 96 96^2 = 9216 96^3 = 884736 96^4 = 84934656 96^5 = 8153726976 96^7 = 75144747810816 96^8 = 7213895789838336 96^9 = 692533995824480256 96^10 = 66483263599150104576 96^11 = 6382393305518410039296 96^12 = 612709757329767363772416 96^13 = 58820136703657666922151936 96^14 = 5646733123551136024526585856 96^15 = 542086379860909058354552242176 96^16 = 52040292466647269602037015248896 Add them all up, and it takes 52588085018927767176012541830240 or fifty two nonillion. five hundred eighty eight octillion. eighty five septillion. eighteen sextillion. nine hundred twenty seven quintillion. seven hundred sixty seven quadrillion. one hundred seventy six trillion. twelve billion. five hundred forty one million. eight hundred thirty thousand. two hundred forty. attempts to find that a user has a 17 character, or larger, password (or one that does not contain one of the 96 common characters in the ASCII character set). FOLKS, THATS A BIG NUMBER... Now, if I desire to know someones password, on any machine, all I need to do is to watch them type it. I can count the characters that they type, watch their hand movements, and that gives me a pretty good indication of what their password is. From there, I could write a program to hash passwords of some close length to the number of characters that I counted, and make guesses about the relative side of the keyboard each character is on. Scared yet about letting me watch you log on? The point is, people who really desire to have access will do one of three things. Either they will obtain authorized access, they will try to break in and get caught in the act, or they will succeed, and you may never know about it. You should be worried, but you should also not be paranoid. I almost agree with Jerry Pournelle or whoever it was that said AT&T should copy protect UNIX. In one year it would be the most popular OS in the industry, because everyone would want to copy it... Gregg Wonderly Mathematics Department Oklahoma State University