Improving password security

[J Greely]

In article <21670 at pbhya.PacBell.COM> whh at 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 at 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 ..."
<WHAM!> "...except the one with the saran wrap and the yogurt."