"Ken Leonard" <kleonard%vhslan@gvlv2.GVL.Unisys.COM> Thu, 05 April 1990 14:18 UTC

Received: from gvlv2.GVL.Unisys.COM by (5.61/2.2) id AA00855; Thu, 5 Apr 90 10:18:42 -0400
Received: by gvlv2.GVL.Unisys.COM (5.61/mls/3.1) id AA00871; Thu, 5 Apr 90 10:18:36 -0400
Received: by vhslan (UUPC/pcmail 1.095b) with UUCP; Thu, 05 Apr 90 09:21:19 EST
Date: Thu, 05 Apr 90 09:21:19 EST
From: "Ken Leonard" <kleonard%vhslan@gvlv2.GVL.Unisys.COM>
Message-Id: <261b545f.vhslan@vhslan>
X-Mailer: Mush 6.5.6 (PC R6.3 22-Sep-89)
Subject: reply

> Art, wrote:
> >
> >...
> > "obvious" choices (these choices are not suitable for discussion in
> > this public medium!!) and checks them against the password files.  If
> >...
> >     How do we tell the system managers how to check for obvious
> > passwords without giving the same advice to malfeasors?  Hiding a
> >...
> Oh, BALONEY!  The "usual" folds, reversals, permu-mungations of
> userids, syswords, dictonarywords -to- passwords are well and widely
> known.
> "Crackers" have usually lots of cpucycles, clocktime or other resources
> to spend rather freely in trying to match a password--they have little
> concern with efficiency of the programs and inner-algorithms they use,
> so they go ahead and do their thing, and we (sysowners, sysusers) end
> up suffering.
> "Legitimate" "anti-crackers have to be concerned about peopletime,
> systime, clocktime, cpucycles and goodness know what other resources
> we have or don't-have available to spend on protective measures.
> Distributing effective algorithms for generating/checking safe
> passwords is what _we_ need.
> "So what," if a cracker gets ahold of a more efficient algorithm?
> He or she may or may not use it, but _will_ continue the attack
> anyhow.  We "goodguys" _need_ efficient algorithms and, without them,
> _may_not_be_able_ to do _any_ protection (almost.)
> "IMHO," playing cutesy-cozy with efficient safety mechanisms is
> _really_ _anti_social_.
> -------------------
> #SET flame=off
> -----
> regardz,
> Ken

Ken Leonard
I'm too old to know better.