Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!mcsun!ukc!dcl-cs!gdt!gdr!exspes
From: exspes@gdr.bath.ac.uk (P E Smee)
Newsgroups: comp.unix.questions
Subject: Re: passwds and crypt(3)...
Message-ID: <1990Jan4.111940.18769@gdt.bath.ac.uk>
Date: 4 Jan 90 11:19:40 GMT
References: <1990Jan3.103141.9903@gdt.bath.ac.uk> <21913@adm.BRL.MIL> <1990Jan2.222052.915@athena.mit.edu> <1990Jan3.204103.9684@athena.mit.edu>
Reply-To: exspes@gdr.bath.ac.uk (P E Smee)
Organization: University of Bristol c/o University of Bath
Lines: 57

In article <1990Jan3.204103.9684@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes:
>In article <1990Jan3.103141.9903@gdt.bath.ac.uk>, exspes@gdr.bath.ac.uk
>(P E Smee) writes:
>> Unstated, but implicit, is the fact that it is even worse if the perpetrator
>> just wants to break *some* password(s), not necessarily yours.  Having
>> encrypted a 'trial' password once, it can then be checked against all
>> encrypted passwords in /etc/passwd to see if it gets any hits.
>
>  (I'm not sure if you already know this, but it sounds like you don't
>-- I may just be understanding what you're trying to say wrong.)
>
>  No, that's the whole point of the seed.  The seed is *different* for
>each encrypted password in the /etc/passwd file (or, at the very least,
>there are a number of different seeds), so trial passwords must be
>encrypted in each possible seed before they can be compared to encrypted
>passwords.

Yep, I know that but chose to ignore it in interests of simplicity.  It
is (still) much faster (and very effective) to encrypt each potential
password (say, the spell-check dictionary plus a list of common first
names) with each possible seed, and check against all encrypted
passwords in /etc/passwd to see if you get any hits, than to try to
crack a particular password.  (There are, as I recall, only a small
number of seeds -- 4k-ish, maybe?)  And (as our crackers did on
Multics) each time you acquire a new password, you can use that userid
to take over part of the list of words to check, so you get
multi-tasking cracking, without imposing a suspicious increase in
resource use on any userid.  (You can also somewhat cover your tracks
by putting the 'smoking gun' files into the filespace of some innocent
bystander whose account you've subverted.)

What I'm not aware of is how the seed is chosen for a user.  If it is
anything other than random, then you can actually put some subtlety in
the trawling algorithm to speed it up.  (Multics used the password as
both data-to-encrypt, and as the seed for encryption.  This was
*claimed* to make it harder to decrypt a particular encrypted password
that you'd found, but actually made the trawling method easier.)

Whether a trawl is 'acceptable' depends on why you want to crack the
system.  Our crackers were registered users who wanted more resources
than we had allocated them.  So, cracking a privileged id wasn't
necessary.  *Any* cracked ID would let them at more CPU and disk
space.  Any cracked 'academic staff' ID would get them network access.
By checking 'last login date' in the greetings message each time they
first logged into a newly cracked account, they could make an educated
judgement as to whether the person was a frequent user, and so as to
how likely he or she was to notice the illicit use.

I'd add in passing that I question the wisdom of putting 'last logged
in at' into the startup greeting.  My experience is that (as above) it
can be useful for crackers, and that it gains you next to nothing in
security terms, as the vast majority of legitimate users don't pay any
attention to it at all -- just part of the noise the machine spits at
you when you log on, to be ignored.
-- 
Paul Smee, Univ of Bristol Comp Centre, Bristol BS8 1TW, Tel +44 272 303132
 Smee@bristol.ac.uk  :-)  (..!uunet!ukc!gdr.bath.ac.uk!exspes if you MUST)