Re: Strong Passwords Revisited
From: Lohkee (Lohkee@worldnet.att.net)
- Next message: nightspore: "Re: Netstat weirdness"
- Previous message: lurker: "Re: Random"
- In reply to: John Elsbury: "Re: Strong Passwords Revisited"
- Next in thread: Tweetie Pooh: "Re: Strong Passwords Revisited"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: "Lohkee" <Lohkee@worldnet.att.net> Date: Tue, 21 Jan 2003 02:07:22 GMT
"John Elsbury" <firstname.lastname@example.org> wrote in message
> On Sun, 19 Jan 2003 21:04:59 GMT, "Lohkee" <Lohkee@worldnet.att.net>
> >On one hand we have an "attacker" who is literally handed the
> >password file which he then runs against a password cracker on a
> >system at extremely high speeds (essentially an unlimited number of
> >to identify a given password), on the other hand we have an attacker who
> >must first somehow penetrate your system and successfully capture the
> >password file (all without ever being detected and stopped - in which
> >you have a far more serious problem on your hands than weak passwords)
> >before he can even begin to think about cracking those passwords!
> >to equate these two vastly different scenarios is absurd. Think about it
> >a moment; hackers would have had free rein on almost every system
> >imaginable for the past twenty years if the results typically obtained by
> >password crackers were representative of anything even remotely close to
> I think that says it all. A password is one of a set of control
> measures, and has to be seen in that context. Other control measures
> in the set include:
> Not making the password file (even encrypted) available to anybody
> other than those with a genuine need;
> Not allowing users to reuse passwords;
> Forcing periodic password expiry;
> Blocking / disbaling login accounts after a (small) set number of
> failed access attempts;
> Logging and auditing exception conditions (such as failed password
> There is a convenience / security formula which will include factors
> * Password length and composition rules (to avoid trivial passwords)
> -vs - probability that a user will have trouble remembering them;
> * Number of attempts before account gets locked -vs - probability that
> legitimate users will get locked out (or have their access denied by
> mischievous persons) - vs - probability that a wild guess will
> * Cost/Number of Help Desk calls arising from forgotten passwords -vs
> - incidence of forgotten passwords (tokens like SecurID sell based on
> this margin)
> Frequency and quality of exception audit and follow-up activity.
All of which can be measured and evaluated mathematically. Security through
science or security through superstition. To me, it's a no-brainier
(although I do admit seem to being in a very, very small minority - welcome
to the club john)!