Source Code 1992 March/Source_Code_CD-ROM_Walnut_Creek_March_1992.iso/usenet/altsrcs/3/3892/APPENDIX

Text File | 1991-08-23 | 12.4 KB | 278 lines

Odds and sods that I thought are interesting:

********

Several people have asked me why I don't write Crack so that it
distributes dictionaries over the network and hacks the same password
file on each machine, as opposed to spreading users over the network and
using the same dictionaries.

There are several reasons for this, which I will outline.

The reasoning that spreading the dictionaries over the network is faster
is correct in the case of cracking the passwords of ONE user - it is
most efficient to run different dictionaries on him on several machines,
and you will break his password eventually.

Scaling this by a factor of 'n' users causes problems.  Firstly, if a
machine guesses one persons password, it must inform all others on the
network not to waste time cracking him, but to get on with the other
users.  This is difficult and nasty.

Secondly, it is not what Crack was designed to do.  The name "Crack" is
actually a misnomer - Crack really ought to be called "Passwdcheck" or
something similar, but such names lack sex appeal.

Crack is not a program designed to break the password of every user in
the file.  Rather, it is designed to find weak passwords in the file, by
attacking those sorts of bad passwords which are most likely to be used,
in the order in which they would most easily be found (ie: are most
likely to be used by a moronic user).

Crack is not designed to break user passwords; it is designed to break
password files.  This is a subtle but important distinction.

If you want to break into a safe, you do not take a hammer at every bit
of it in turn; instead, first you try some simple combinations, then you
try blowing the hinges off, then you get out an acetylene torch and go
for the bolt.  If that doesnt work, THEN you start on the walls.  You go
for the bits which are most likely to be weak first.

Consider a password file with 'n' users in it.  Say that your serial
password cracker uses a dictionary of 1000 words, and tries each word 6
ways (upper/lower/mixed case, permuted with forwards/backwards)

Also consider that out of that 1000 users, only one (the last one) has a
guessable password - "fred".

Also say that it takes time 'T' seconds to encrypt a word.

If you use the "try each user in turn" method, like the COPS password
cracker, you will have to wait for a time:-

    999 users * 1000 words * 6 ways * T = 5994000 T seconds

before you get to that last user.  Spreading this load around on a
network only alleviates the number of words to be searched (divides them
by the number of machines you are working on).

Thus, if you use 10 machines, the machine which will guess "fred" will
get to that last user in:-

    999 * (1000 / 10) * 6 ways = 599400 T seconds.

Alternatively you can try it the Crack way - "fred" is a word which
appears in a forwards dictionary.  You will only wait:-

    999 users * 1000 words * 1st way * T = 999000 T seconds

to get to that user.  Now split the _USERS_ across 10 machines:-

    (999 / 10) users * 1000 words * 1st way = 99900 T seconds

To get to his password, in ONLY 17% of the time taken by networking
using the serial cracking method.  This is only a boundary case, but I
hope I have illustrated the concept.

********

Crack has several other optimisations because of its structured password
guesses.  The figures below are entirely empirical, but I reckon that
they're as good as any:

The first pass that Crack makes is over the user data user information
gleaned from the users' password field.  In my test file, this gets
about 3% of the passwords (out of a total of 11% guessed).  This pass
also completes the quickest of all, working as it does from a very small
amount of data, but one which is very frequently used for passwords.

My test password file is 1150 users big, and the first pass completes in
a little over 2 minutes.  In that time Crack gets 35 accounts.

The first sweep of the second pass, consisting of lowercase dictionary
words, gets about another 5% of the passwords.  This means that, for our
1150 users, we have now cracked a cumulative total of 91 accounts.  The
length of the first sweep depends on how much CPU and how many
dictionaries I supply, but using the Ultrix /usr/dict/words and my
bad_pws.dat, over 4 CPUs, it doesn't take much more that a couple of
hours.

For the further sweeps, the percentages cracked per sweep tail off, 2%,
1%, 0.5%...  But they are the people with fairly exotic passwords, and
it's only common sense that that they will take some time to crack.

********

There is one more major optimisation that I haven't mentioned.  Because
of the way the UNIX crypt() algorithm works, each encryption is "salted"
with a two letter sequence which is stored as the first two characters
of the encrypted password.  This salting means that the word "fred" can
be encrypted and appear in a password file in (literally) thousands of
different ways - so long as each encryption has a different salt.

Hence, it makes sense to do things in this manner:

1) sort and group the input data by encryption salt.
2) for each different groups' encryption salt
    * get a dictionary word
    * encrypt it using that salt (This is the time consuming bit)
    * compare the encryption with each member of the group with that salt
    * if it matches, you have guessed that users password.

This knocks (empirical guesswork time again) up to one third of the
dictionary encryptions off - thus saving you 0.3 of the time all the
dictionary sweeps would ordinarily take.  You can work out this figure
yourself: Crack gives this statistic when it says

    pwc: Loaded 'n' password entries into 'm' salted lines.

so you can work out the percentage of users who have the same salt:-

            x = (m / n) * 100

and hence the percentage of encryption time that you save = (100 - x).

********

Listening to the REM album 'Green' on the way back from the Cropredy
folk festival yesterday, whilst I was thinking over things to do to
Crack, and I was struck (not for the first time) by the words of the
first verse to 'World Leader Pretend':-

    I sit at my table, and wage war upon myself.
    It seems like it's all, it's all for nothing.
    I know the barricades, and I know the mortar in the wall
    I recognise the weapons, I use them well.

    This is my mistake, let me make it good,
    I raised the wall, and I will be the one to knock it down...

- writing password cracking programs gets to you after a bit.

********

Some people have asked me how to generate safe passwords.  This, sadly,
has become a religious issue, and there are now, on USENET, several
vociferous "password geeks" who will say "my method is the best", in the
same way that some mathematicians will try to compare so-called "random
number generating algorithms".  Such statements are pointless.  I'm
sorry for adding to the confusion, but I must say that I think they are
wrong.

Okay, so I am a security fatalist and a security philosopher, but I am
not going to give and hard and fast answers; rather, I'd like to make
some points and recommendations to the people out there.  Security isn't
a tangible thing, it is applied psychology.

The whole point of a password is to prevent people accessing your
system, getting into it from outside.  Once someone is inside your
system, assuming that they have the relevant knowledge of your O/S, it
is safest to assume that anyone can get to be 'superuser'.  Your only
security once someone is on your system is called "security by
obscurity".  If your user has sufficient knowledge, you've "had it".

The question isn't "How secure can my system be made?".

The question really should be, "How much do I care, how much can I trust?".

A system can be perfectly secure without any passwords at all, so long
as it is in an environment of people who recognise its purpose and
depend on it.  I say this after having had acounts on several 'public'
machines, which could have been taken to bits by any competent Unix
person, but were largely safe - because when someone worked out who did
anything nasty, the culprit was ostracised from the community.  There
_is_ a caveat to this, however.

The problem is the sort of people who go around the world 'collecting'
computer accounts and breaking machines, those who have either a
childish mentality or an ulterior motive.

The former are like the little boys who go around breaking windows and
vandalising things 'for kicks'.  They are the ones who see every
password file as a "NO ENTRY" sign, and therefore, driven by what they
think is anarchy and fun, they break in and smash the place up.  Tell
them that they are behaving like children, and they will behave moreso.

The latter are driven by personal motives or money.  Their reasons are
too complex for me to analyse here.

The 'babyish' hackers need a lesson (which I hope that eventually they
learn) that true anarchy is for the general good, and is best achieved
by fiat amongst the community.  USENET is a good example - there is a
lot of petty bickering and arguing, but an incredible amount of good
comes out of it.  It is anarchy that the old greek philosophers would
have approved of.

What I am trying to say is that, when I say that if someone gets into
your system, you've "had it", you should consider whether there is
anything to have "had" in the first place.  There is no point in getting
yourself paranoid over security - if you do, you'll lose out.  Don't be
too paranoid.  Be SENSIBLE instead, and secure your system according to
it's needs, and not according to some 'holy bible' of absolute security.

If someone gets into your system, you find out how they did it, patch
the hole, check for back doors, brush yourself off, and start again.
It's not the end of the world.

What this statement doesn't address (yet) is the needs of system
managers who have a REAL need for security - be it corporate data or
research work - on their system.  As I have said before, most O/S's have
gaping holes in them that cannot be entirely filled, and so the users
must be stopped on the doorstep.  At the password login.

People who say that they have a way of generating safe passwords are
misinformed, IMHO.  Saying that the password "wyufwqpl" is secure is as
meaningful as saying that the number "4" is random.  Password security,
like any other form of computer security, is not an absolute, but should
be taken in context.

You can't say that a certain method will provide secure, random
passwords, because, in defining an algorithm to create these passwords,
you will use only a subset of all the possible passwords that could ever
exist.  You have shrunk the 'search space' for the passwords.

Someone merely has to write a password cracker which will search this
small subset of passwords, in order to break your system.  Passwords
generated by any algorithm, human or computer based, are merly
pseudo-secure, in the same way that numbers can be pseudo-random.  For
illustration of this aspect of password security, read the document
"Password Security, A Case History" by Morris and Thompson.

There is an incredibly large set of possible passwords in the world, and
the best approach toward choosing a password is not to try to find a way
to generate 'secure' passwords - there are no such things - but rather
you should learn to choose passwords which are not easily searched for.
Passwords which are out of the 'search space' of most password crackers
like 'Crack'.

Read the Crack documentation.  See what sort of things other programs
like Crack would search for.  Think of some yourself.  I am not going to
specifically mention methods, you should really work something out for
yourself.

At the bottom line, the password "fred" is just as secure (random) as
the password "blurflpox"; the only problem is that "fred" is in a more
easily searched part of the "password space".

Both of these passwords are more easily found than "Dxk&2+15^N" however.
Now you must ask yourself if you can cope with remembering "Dxk&2+15^N".

8-)

********

I'd like to thank Chris Samuel & Piercarlo (Peter) Grandi for all their
help in beta-testing Crack, and in Peter's case especially, for dropping
me into the deep end of troff.  Die, you bastard.  8->

I'd also like to thank Chris Myers for giving me an archive site to work
from (saving me a lot of tedious email) and heaps of suggestions.

Similarly for Randal Schwartz for his information and Chris Lewis (the
psroff guy) for all his suggestions.
                        - alec
--
INET: [e-mail]      JANET: [e-mail]      BITNET: aem%aber@ukacrl
UUCP: ...!mcsun!ukc!aber!aem         ARPA: [e-mail]
SNAIL: Alec Muffett, Computer Unit, Llandinam UCW, Aberystwyth, UK, SY23 3DB