🚀 go-pugleaf

hubcap@hubcap.clemson.edu (System Janitor) writes:
>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
>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? 

This is a hard statement to agree with, given that it is only a matter 
of time before someone puts crack-like word scanning in npasswd. 

Keep in mind that scanning plaintext matches is far faster than scanning 
crypted ones.

-- 
Dave Hayes - Network & Communications Engineering - JPL / NASA - Pasadena CA
dave@elxr.jpl.nasa.gov       dave@jato.jpl.nasa.gov         ...usc!elroy!dxh

    If it works...use it. If it doesn't, find out why and use THAT. 

dave@jato.jpl.nasa.gov (Dave Hayes) writes:

>hubcap@hubcap.clemson.edu (System Janitor) writes:
>>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
>>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? 

>This is a hard statement to agree with, given that it is only a matter 
>of time before someone puts crack-like word scanning in npasswd. 

>Keep in mind that scanning plaintext matches is far faster than scanning 
>crypted ones.

>-- 
>Dave Hayes - Network & Communications Engineering - JPL / NASA - Pasadena CA
>dave@elxr.jpl.nasa.gov       dave@jato.jpl.nasa.gov         ...usc!elroy!dxh

>    If it works...use it. If it doesn't, find out why and use THAT. 

And given that you have that plaintext password at this point, you don't have
to search anything like the whole dictionary since after doing the transform
you can eliminate all entries that for instance don't match the first letter
of the word (assuming a sorted dictionary) cutting the work down to a managable
level.
	Even now when this isn't true, it reduces the number of bad passwords
that they have to find with Crack before you do. Npassword isn't an end in
itself, you still need to do a bunch more things, but it is one of the things
that helps.


Peter Van Epp / Operations and Technical Support 
Simon Fraser University, Burnaby, B.C. Canada

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.
>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.

Why should that be time consuming?  Space consuming, yes?  But not time
consuming.  Ever hear of a binary search? ;-)

>
>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
>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? 

With that kind of logic why bother with security at all?  If you figure that
unless you have extreme measures any given site on the Internet will be hit by
crackers eventually you could just chuck all the security checking altogether,
couldn't you?  If you really do check a 800,000 word dictionary with 300
transmorgrifications each a cracker would have to work a REALLY long time to
get even one password, making it more likely for someone to notice him.  Its
certainly an improvement over the alternative, isn't it?

-- 
/-----------------------------------------------------------------------------\
| Doug Siebert                             | "I don't have to take this abuse |
| Internet:  dsiebert@icaen.uiowa.edu      |  from you - I've got hundreds of |
| NeXTMail:  dsiebert@chop.isca.uiowa.edu  |  people waiting in line to abuse |
|     ICBM:  41d 39m 55s N, 91d 30m 43s W  |  me!"  Bill Murray, Ghostbusters |
\-----------------------------------------------------------------------------/
Hi, I'm a .signature worm.  I've already copied myself into your .signature.

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.  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.

But remember - if n is the number of words you want to check against
(say, 20000 words * 15 transformations = 300k words), you only have to
do O(log n) comparisons. Your password cracker is going to be doing
O(n) comparisons, and she's going to be doing it through a slow crypt
function. You win.

Furthermore, there's no reason in principle that the crack 4.1 word
generation engine (which is excellent) can't be grafted into npasswd.
I keep hoping someone else will do the work for me.

>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 have some userids from which to launch their nefarious plans.

yes, but if you have 2000 users and only 10 of the passwords are
crackable, then it will take a *long* time for the "nefarious cracker"
to get at those passwords.

Security is a game of staying ahead, not being perfect.
-- 
                __
nelson@reed.edu \/   Delicious & Nutritious breakfast cereals shot from guns!

In article <PCL.92Jul27140810@black.oxford.ac.uk> pcl@oxford.ac.uk (Paul Leyland) writes:
#At our site, I *may* have found a problem, though I have no idea
#whether I broke the Ultrix specific code, or if it is a bug in the
#generic code.  This under Ultrix v4.2a
#
#Third-party password changes sometimes change *root's* password.  That
#is, suppose I (pcl) am approached by jruser to change their password.
#I type something like:
#	% \/bin/su - root
#	Password:
#	# npasswd jruser
#	...
#
#If I make a typo at this point, and have to have another go at
#changing jruser's password (still in the same invocation of npasswd,
#BTW) and succeed in getting a password through, I *sometimes* find
#that root's password has been changed and the user's has not.  My
#password is left unchanged. (Phew!)

I have not experienced this on Suns (yet!).  This is running the pw_yp.c
code to update NIS passwords if there is no local password.  The main hacks
I have made are to update a separate NIS password age database if a NIS
password has been successfully changed.

Mark

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.

dsiebert@icaen.uiowa.edu (Doug Siebert) writes:

>With that kind of logic why bother with security at all?  

Now now. Calm down. I don't think my logic makes me that much of a kook.
I want an unCrackable password file. I haven't yet come up with how to 
get one. npasswd, which has been defended nicely here since I first posted,
doesn't seem like the way to get an unCrackable password file. Nobody
wants draconian security measures that get in the user's ways, so what
we need is a simple elegant way to get an unCrackable password file.
There may not be a simple elegant way to get an unCrackable password file. 
That doesn't stop us from looking for one. 

>If you really do check a 800,000 word dictionary with 300
>transmorgrifications each a cracker would have to work a REALLY long time to
>get even one password

It takes a long time to run to completion, but it doesn't take long at all 
to get lots of passwords. After the first rush of easy-to-guess passwords
spews out (these are the ones I would expect npasswd to cut down on) then
harder ones continue to dribble out for days. I wouldn't expect npasswd
to make that much of an impact on these.  npasswd is a good thing in its 
own light, but I always thought it sprang up as a (flawed) way to fight crack. 

I'll try to scrounge up the time (to convince a graduate student :-) to 
graft crack to npasswd (seems like someone would have already done that) 
and then hook it to our 800,000 word dictionary and 300 rulesets and see 
how long it takes. Already this discussion has suggested some optimizations 
on how to zip through the rulesets.

-Mike

Humorous aside: A local user set his password to a ``random'' string
of lower case letters. While Crack was going through the rock-star 
dictionary, and was checking for the drummer of Metalica backwards, it
got him!

In article <1992Jul28.012207.27248@news.uiowa.edu>, dsiebert@icaen.uiowa.edu (Doug Siebert) writes:
|> Why should that be time consuming?  Space consuming, yes?  But not time
|> consuming.  Ever hear of a binary search? ;-)
|> 
My locally-developed passwd/yppasswd replacement program does just that.
Searching a (currently 116K-word) dictionary with a binary search takes a
  small fraction of a second.

-- 
Marcus Leech, 4Y11             Bell-Northern Research  |opinions expressed
mleech@bnr.ca                  P.O. Box 3511, Stn. C   |are my own, and not
ml@ve3mdl.ampr.org             Ottawa, ON, CAN K1Y 4H7 |necessarily BNRs

In <1992Jul28.035951.22683@reed.edu> nelson@reed.edu (Nelson Minar) writes:

>Furthermore, there's no reason in principle that the crack 4.1 word
>generation engine (which is excellent) can't be grafted into npasswd.
>I keep hoping someone else will do the work for me.

Why not just alter npasswd to force at least one upper case letter, one
digit plus one non-alphanumeric?   Such passwords can still be remembered
reasonably easily and are very resistant to cracking programs.  

Tim

In <71269183717599@juju.mcs.anl.gov> nickless@juju.mcs.anl.gov (Bill Nickless):
>Currently the file looks like this:
>-rw-r--r--  1 nickless 107137306 Jul 12 20:40 bigdict.sorted
>You then do a binary search against this.  The search probe scans for the 
>first full word near the computed byte address.  Once you narrow it down 
>to about 100 bytes then a simple linear search happens.

Knowing where the binary search finished would tell a cracker the first
few characters of the actual password, greatly reducing the search space.

If they can snoop NFS packets off the ethernet they can learn this
directly.  If they can login to either the NFS server, or the client
where the password change took place, it might also be possible to
figure it out by the doing timed reads on the bigdict.sorted file
and intuiting which reads were satified from the buffer cache and
which required physical I/O.
-- 
Jim Prescott	jgp@moscom.com		{rit,tropix,ur-valhalla}!moscom!jgp