Path: utzoo!attcan!uunet!pyrdc!pyrnj!rutgers!tut.cis.ohio-state.edu!banjo.cis.ohio-state.edu!jgreely From: jgreely@banjo.cis.ohio-state.edu (J Greely) Newsgroups: comp.unix.wizards Subject: Re: Improving password security Keywords: password, security, brute-force Message-ID: <27987@tut.cis.ohio-state.edu> Date: 19 Nov 88 23:38:54 GMT References: <21670@pbhya.PacBell.COM> Sender: news@tut.cis.ohio-state.edu Organization: THE Ohio State University, CIS Dept. Lines: 63 In article <21670@pbhya.PacBell.COM> whh@pbhya.PacBell.COM (Wilson Heydt) writes: >it is noted that the standard >Unix schemeuses the passowrd as the encryption key on a standard >plaintext. More specifically, the plaintext is 0x0000000000000000, encrypted 25 times with a variant of DES. > Would it not be a great help in stopping brute-force >attacks to make the plain-text configurable by binary-licnese sites? Depends on the attack (see below). All a different plaintext accomplishes is forcing the cracker to recompile his cracker with a new plaintext (and pre-running the initial permutation, for speed). >Then the attacker would have to either break to the plain text for >each site--difficult enough in itself, restrict itself to some >subset of the possible plaintexts, or generate an implausibly large >dictionary. point by point: 1. break the plaintext: trivial to do, if I can read libc.a on your system. Since crypt is a standard library function, the object file is open to anyone who wants it. Your secret plaintext is secret only so long as no one is allowed to use the crypt function. Of course, you can remove crypt.o from libc.a, and hide it somewhere for rebuilding system utilities (which you'll at least need unlinked objects for). Messy, but it does add some security. You *will* be surprised at how many programs use it, though. Oh, and don't forget to shut off world read permissions for any program you link it into. 2. possible plaintexts: 2^64, non-trivial (no kidding). 3. large dictionary: pre-encrypting /usr/dict/words with all of the possible salts uses up just about a gig of disk, (11 bytes per encryption, 4096 salts, 25000 words). Generating this is non- trivial: 102,400,000 encryptions; figure about 5 crypts/second on a Sun 3/50, or 237 days to generate this with one Sun (assuming sufficient disk space). Of course, we have over 200 suns here, reducing that to a very reasonable time. Once I know your plaintext, I have plenty of time to generate passwords. How often do you plan on changing it, remembering that all of your users have to change their passwords every time you change the plaintext? I'll just fill a box of tapes, write your site's name on them, and save them "for later" (half :-)). Did I mention that we've managed a 45% speed improvement in the crypt function (and we're not done speeding it up yet)? >Am I off base? Merely out of date? Or has this been (or is this >being) done? It *is* a good idea, just not easy in practice (particularly for binary sites). -=- J Greely (jgreely@cis.ohio-state.edu; osu-cis!jgreely) "By focusing my awareness upon the void that is beyond 'self', I was able to transcend each humilitation ..." "...except the one with the saran wrap and the yogurt."