home *** CD-ROM | disk | FTP | other *** search
- Xref: sparky comp.security.misc:842 alt.security:4027 comp.unix.ultrix:5928
- Path: sparky!uunet!mcsun!uknet!ox-prg!nnhost!pcl
- From: pcl@oxford.ac.uk (Paul Leyland)
- Newsgroups: comp.security.misc,alt.security,comp.unix.ultrix
- Subject: Re: Problem with npasswd??
- Message-ID: <PCL.92Jul28114638@black.oxford.ac.uk>
- Date: 28 Jul 92 10:46:38 GMT
- References: <PCL.92Jul27140810@black.oxford.ac.uk>
- <1992Jul27.184324.14697@hubcap.clemson.edu>
- Sender: news@comlab.ox.ac.uk
- Organization: Oxford University Computing Service, 13 Banbury Rd, Oxford, OX2
- 6NN
- Lines: 75
- In-reply-to: hubcap@hubcap.clemson.edu's message of 27 Jul 92 18:43:24 GMT
-
- In article <1992Jul27.184324.14697@hubcap.clemson.edu> hubcap@hubcap.clemson.edu (System Janitor) writes:
-
- > Unless I am mistaken, npasswd doesn't check for everything crack does.
-
- You are correct.
-
- > Even dropping the time consuming crypt part, it seems like it would
- > take an unacceptable amount of time to change your password if it were
- > checked against, say, an 800,000 word dictionary with 300 transmogrification
- > rulesets.
-
- I don't know. I could experiment, I suppose. Looking up a word in a
- 800k entry dictionary only takes about 30% more time than looking it
- up in the 25k entry /usr/dict/words. (A binary search is used, on the
- assumption that the dictionary is sorted, so we're comparing 2**20
- against 2**15: 20/15 = 1.33). Some rulesets could be dismissed
- without doing the dictionary check. For instance "append 2" will fail
- if the candidate does not end in 2. I suspect that full Crack testing
- would not greatly increase checking time if optimisations like this
- were included.
-
- > The point is, even if you use npasswd, a cracker will still get some of
- > your passwords. So what if they only get 10 instead of 200, they'll still
-
- In my experience, the efficacy of Crack drops to near zero when it has
- been used to crack a system's passwords *and the broken accounts are
- disabled*. Users really do learn to choose Crack-resistant passwords
- if they are required to come in with proof of identity before they can
- use their account again. Npasswd helps them to choose Crack-resistant
- passwords.
-
- In my experience, a naive Unix site will have 20-30% guessable
- passwords. A Crack- and npasswd -free site, but otherwise fairly
- security concious will yield 10-15%. After the first iteration of
- Crack and account disabling, I found four passwords out of several
- hundred -- around 1%. After two iterations I didn't break a single
- account.
-
- > have some userids from which to launch their nefarious plans.
- > So, aren't you fooling yourself to think that npasswd like schemes
- > enhance your system security enough to make them worthwhile?
-
- I don't think so. It is a relatively cheap addition to password
- security. Admittedly, it isn't perfect; nothing in this life is.
-
- However, it has two important benefits. First, it ensures that the
- simple Crack rules won't work. Minor benefit, as one can always
- re-order the rules to do the bizarre ones first.
-
- Secondly, and much more importantly in my view: it gets the user to
- *think* about password security. If forced to use non-trivial
- passwords, people tend to become quite creative. They also tend to
- carry this creativity to other systems where it is not strictly
- ncessary, but still desirable.
-
- > I realize there is a need for this kind of security, and of course, I
- > don't have the right answer. But it doesn't seem like npasswd is it.
- > Discussion?
-
- Npasswd does *not* solve all of life's problems. It is a useful tool;
- nothing more. Shadow passwords, password aging and other such
- techniques are also useful tools. People who believe they can solve
- the security problem are deluding themselves. The best we can do with
- current technology is to increase the cost/benefit ratio for crackers,
- to the point where it is (probably) not worth the effort, without
- increasing it too much for authorised users. What "too much" means
- depends strongly on local circumstances.
-
- Paul
-
- --
- Paul Leyland <pcl@oxford.ac.uk> | Hanging on in quiet desperation is
- Oxford University Computing Service | the English way.
- 13 Banbury Road, Oxford, OX2 6NN, UK | The time is come, the song is over.
- Tel: +44-865-273200 Fax: +44-865-273275 | Thought I'd something more to say.
-