Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

The "Crack" Password Cracker v3.0 : - RFC and help!.

14 views
Skip to first unread message

Alec David Muffett

unread,
Jul 22, 1991, 7:34:33 AM7/22/91
to
Hi.

For anyone who has seen it, I'm working on Crack 3.0 right now, and
thought you might like to suggest further improvements (within reason);

What I have covered (or am covering) so far is:-

1) Moving all those nasty little platform specific options into a single
"conf.h" - which is then written with a user-friendly shell script. The
script will also prompt for your favourite C compiler, additional
dictionaries of words, etc.

2) Multiple binary formats in different subdirectories, because of the...

3) Multi-host configuration option, which splits the load evenly across
several hosts to achieve a degree of multiprocessing (Using "rsh" since
I am NOT going to try to get too clever here yet...). Thus the need for
different architecture hacking.

4) Support for parallel architectures like Sequents. If anyone can
advise me on how best to do this other than the obvious "fork() several
times" solution, please let me know.

- I've whanged a few extra options in, mostly to hush Dan Farmer up
[8-)] so that, with a bit of thought, "Crack" does everything that the
COPS password cracker does, so long as it's sensible.

The following can all be switched on/off:-
- it tries the username as a password, eg: "root"
- it tries the username *doubled* as a password, eg: "rootroot"
- it hacks through a users' gecos field looking for passwords.
(all of the above are done forwards, sdrawkcab, UPPER, lower & Plaintext)
- it reports null passwords with a warning.
- it reports locked passwords (beginning with '*' or '!' as unbreakable.
- it can be configured not to try dicrionary guesses < 5 chars long,
as on some systems this is a dreadful waste of time.
- it outputs each guess as it tries it (ie: fills up your filestore)
- it prints the password of the user when guessed (if you want to see it)

As for the other COPS options:
- single letters and digits as passwords are now provided in the additional
dictionary "bad_pws.dat"
- Uppercasing and lowercasing are done by a preprocessor, so there is no
overhead on this operation and switching these options off does nothing
useful, because of the way that Crack is structured.

Any other suggestions ?

One surprising thing to come out of posting "Crack" to the net is that I
have not (yet) been flamed for putting such a hazardous program in a
place where the public can get at it. Quite the opposite. A lot of
people (some of whom I think should know better) have asked why I do not
include fcrypt() with "Crack" as standard.

I know that *NOT* distributing fcrypt() has actually confused some
people about how "Crack" works - something I must clarify in the README
file. What are peoples views on posting fcrypt() ?

Before I hear anything though, please take note that at the moment, I
will only post my version of fcrypt() to well-known trusted users, and
at worst to 'root' at a well-known site. Crack+fcrypt() can take a
fairly normal machine to pieces in a matter of minutes, and I think that
it would be thoroughly irresponsible to post it. It will take a lot to
convince me. 8-)

alec
--
INET: a...@aber.ac.uk JANET: a...@uk.ac.aber BITNET: aem%aber@ukacrl
UUCP: ...!mcsun!ukc!aber!aem ARPA: aem%uk.ac...@nsfnet-relay.ac.uk
SNAIL: Alec Muffett, Computer Unit, Llandinam UCW, Aberystwyth, UK, SY23 3DB

David J. Hughes

unread,
Jul 22, 1991, 7:47:42 PM7/22/91
to
From article <1991Jul22....@aber.ac.uk>, by a...@aber.ac.uk (Alec David Muffett):
> Any other suggestions ?

In my opinion, the options supported (or about to be) offer the
functionality that is required. Adding further options would confuse
the average user.

> I know that *NOT* distributing fcrypt() has actually confused some
> people about how "Crack" works - something I must clarify in the README
> file. What are peoples views on posting fcrypt() ?

Being a system administrator it bothers me that I have the same tools as
my users. If it takes me the same time to check the passwd file as it
does for ANY user to crack it then I lose big. Without an edge on the
average Joe User we will stay behind the 8 ball.

> Before I hear anything though, please take note that at the moment, I
> will only post my version of fcrypt() to well-known trusted users, and
> at worst to 'root' at a well-known site. Crack+fcrypt() can take a
> fairly normal machine to pieces in a matter of minutes, and I think that
> it would be thoroughly irresponsible to post it. It will take a lot to
> convince me. 8-)

Expecting root to be a responsible user is not a good thing.
Workstations are to widely used these days for that. Fred Smith may
have an old Sun3/50 on his desk because his boss got a Sparc2 and
didn't need the 3/50 anymore. Suddenly he is ROOT at his box.

It may be a better idea to mail PostMaster at the source domain to get
some reasonable feedback on the user in question. No doubt he will tell
you that Fred Smith is a postgrad doing English Langauge Studies.

For UUCP, maybe the node upstream of the destination host? I'm not big
on UUCP but it could be O.K.


Thoughts ?


bambi
+----------------------------------------------------------------------------+
| David J. Hughes (AKA bambi) | ba...@kirk.bu.oz.au |
| Senior Network Programmer | ba...@kirk.bu.oz.au@uunet.uu.net |
| Comms Development & Operations | ..!uunet!munnari!kirk.bu.oz.au!bambi |
| Bond University, Gold Coast | Phone : +61 75 951450 |
| Queensland, Australia 4229 | Fax : +61 75 951456 |
+----------------------------------------------------------------------------+

Paul Pomes - UofIllinois CSO

unread,
Jul 29, 1991, 2:37:18 PM7/29/91
to
a...@aber.ac.uk (Alec David Muffett) writes:

>Before I hear anything though, please take note that at the moment, I
>will only post my version of fcrypt() to well-known trusted users, and
>at worst to 'root' at a well-known site. Crack+fcrypt() can take a
>fairly normal machine to pieces in a matter of minutes, and I think that
>it would be thoroughly irresponsible to post it. It will take a lot to
>convince me. 8-)

It didn't anything to convince me. Both fcrypt() and pwc.c (which does
most of what crypt 3.0 does) are available for anon-FTP from uxc.cso.uiuc.edu
in the pub/cops.tar.Z file. N.B., the anon-FTP service is down until
Thursday while the disk is replaced.

/pbp
--
Paul Pomes, Computing Services Office | Michigan, in its barbaric wisdom,
University of Illinois - Urbana | is now sentencing first-time drug
Email to Paul-...@uiuc.edu | offenders to life w.o. parole. What
| charming savages.

Jyrki Kuoppala

unread,
Jul 29, 1991, 5:40:03 PM7/29/91
to
>It didn't anything to convince me. Both fcrypt() and pwc.c (which does
>most of what crypt 3.0 does) are available for anon-FTP from uxc.cso.uiuc.edu
>in the pub/cops.tar.Z file. N.B., the anon-FTP service is down until
>Thursday while the disk is replaced.

In sci.crypt, one faster crypt(3) was also just posted. It's said to
be somewhere around 9-24 times faster than the one in libc, depending
on the machine.

It's amazing how many of the passwords on normal Unix machines can be
found by a simple dictionary attack. Does anyone have a summary of
drop-in configurable passwd(1) replacements which do checks against a
dictionary and checks against other simple passwords ?

//Jyrki

John R. Schutz

unread,
Jul 30, 1991, 10:40:02 AM7/30/91
to
j...@cs.HUT.FI (Jyrki Kuoppala) writes:

>It's amazing how many of the passwords on normal Unix machines can be
>found by a simple dictionary attack.

Yup.

>Does anyone have a summary of
>drop-in configurable passwd(1) replacements which do checks against a
>dictionary and checks against other simple passwords ?

As a matter of fact, check out npasswd from Clyde Hoover. You can grab
it at emx.utexas.edu (128.83.1.33) in the /pub/npasswd directory.

Here's the intro to the README:

-- snip snip w/ yer clown scissors --
* Introduction

Npasswd is a pretty-much-plug-compatable replacement for passwd(1).
This version incorporates a password checking system
that disallows simple-minded passwords.

It does exactly ONE thing - change login passwords, though it would
not be too difficult to make it do shells and GECOS stuff also.

I have modeled npasswd after passwd(1) from 4.3BSD and SunOS 4.0, but
it does not impliment the options those versions have.
I have also included support for Sys VR3 password aging, but I don't have
a SysV box around to test it on.
-- clack clack --

john
--
| John R. Schutz | Email&NeXTmail: |
| A learning NeXTie | jo...@csrnxt1.ae.utexas.edu |
| (512)328-0587 | The 23rd periodic element is Vanadium |
| 3009 Hatley Dr., Austin, TX 78746 | 'V'. V is roman numeral for 5. Hmmm |

dan

unread,
Jul 30, 1991, 11:44:22 AM7/30/91
to

In article <john.68...@csrnxt1.ae.utexas.edu> jo...@csrnxt1.ae.utexas.edu (John R. Schutz) writes:
From: jo...@csrnxt1.ae.utexas.edu (John R. Schutz)

>Does anyone have a summary of
>drop-in configurable passwd(1) replacements which do checks against a
>dictionary and checks against other simple passwords ?
As a matter of fact, check out npasswd from Clyde Hoover. You can grab
it at emx.utexas.edu (128.83.1.33) in the /pub/npasswd directory.

There are a few others that I know about -- try matt bishop's, at
dartmouth.edu, ~pub/passwd+.tar.Z, I think, or Wall/Scwartz's from
the perl book -- sould be at uunet somewhere, in the nutshell source
directory (~nutshell/perl maybe?)

-- dan

Staffan Persson

unread,
Jul 30, 1991, 10:05:08 AM7/30/91
to
>It's amazing how many of the passwords on normal Unix machines can be
>found by a simple dictionary attack. Does anyone have a summary of
>drop-in configurable passwd(1) replacements which do checks against a
>dictionary and checks against other simple passwords ?
>
>//Jyrki

OSF offer a password checker build into passwd(1) as a part of the
OSF/1 security offering. It checks for dictionary paswords etc and
has also a password generation build in.

There is also a public domain password checker from Matt Bishop called
the proactive password program. There is an alpha test version
available for anonymous login at dartmouth.edu in pub/passwd+.tar.Z.

Note, these are NOT password cracking programs, instead they disallow
users picking bad passwords when changing passwords with passwd(1).

--
Staffan Persson

Internet: sta...@osf.org, sta...@osf.de
Mail : OSF, Stefan-Georg-Ring 29, D-8000 Munich 81, Germany
Tel. : +49 89 930 92141
Fax. : +49 89 930 92104

Tom Neff

unread,
Aug 5, 1991, 6:49:26 AM8/5/91
to
In article <STAFFAN.91...@helsinki.osf.de> sta...@helsinki.osf.de (Staffan Persson) writes:
>OSF offer a password checker build into passwd(1) as a part of the
>OSF/1 security offering. It checks for dictionary paswords etc and
>has also a password generation build in.

I have an interesting thesis idea for someone.

Build two password checkers. One consults the dictionary and prevents
you from setting an 'easily guessable' password. The other simply
randomly refuses about 40% of the new passwords entered! Install both
checkers, double-blind, and see who has more breakins. :-)

--
"The thought of being President frightens me and I @-@ Tom Neff
do not think I want the job." -- Ronald Reagan, 1973 \_/ tn...@bfmny0.BFM.COM

0 new messages