Path: utzoo!mnetor!uunet!husc6!rutgers!sri-spam!ames!ucbcad!ucbvax!VENUS.YCC.YALE.EDU!LEICHTER From: LEICHTER@VENUS.YCC.YALE.EDU ("Jerry Leichter ", LEICHTER-JERRY@CS.YALE.EDU) Newsgroups: comp.os.vms Subject: Re: 'security holes' Message-ID: <8712292021.AA24296@ucbvax.Berkeley.EDU> Date: 29 Dec 87 17:06:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 111 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