⟦38981e8a7⟧

TextFile

.de C
.ie n .B "\\$1" \\$2
.el .CW "\\$1" \\$2
..
.TL
"Crack Version 4.1"
.br
A Sensible Password Checker for Unix
.AU
Alec D.E. Muffett
.AI
Unix Software Engineer
Aberystwyth, Wales, UK
.I "(aem@aber.ac.uk or alec_muffett@hicom.lut.ac.uk)"
.AB
.B Crack
is a freely available program designed to find standard Unix
eight-character DES encrypted passwords by standard guessing techniques
outlined below.  It is written to be flexible, configurable and fast,
and to be able to make use of several networked hosts via the Berkeley
.C rsh
program (or similar), where possible.
.AE
.NH 1
Statement of Intent
.LP
This package is meant as a proving device to aid the construction of
secure computer systems.  Users of Crack are advised that they may get
severly hassled by authoritarian type sysadmin dudes if they run Crack
without proper authorisation. 
.NH 1
Introduction to Version 4.0
.LP
Crack is now into it's fourth version, and has been reworked extensively
to provide extra functionality, and the purpose of this release is to
consolidate as much of this new functionality into as small a package as
possible.  To this end, Crack may appear to be less configurable: it has
been written on the assumption that you run a fairly modern Unix, one
with BSD functionality, and then patched in order to run on other
systems.
.LP
This, surprisingly enough, has led to neater code, and has made possible
the introduction of greater flexibility which supercedes many of the
options that could be configured in earlier versions of Crack.  In the
same vein, some of the older options are now mandatory.  These, such as
.I "feedback mode"
and
.C CRACK_PRINTOUT
are no longer supported as options and probably never will be again.
There is just a lot of wastage in not running with them, and too many
dependencies in other functions to bother programming around them.
.LP
The user interface is basically identical to the previous versions,
although some people have asked about providing X-windows GUI's to
Crack, I think it would be a waste of time to do so. Crack has far
less options than your ordinary version of
.C /bin/ls .
.NH 1
Introduction to Version 4.1
.LP
Version 4.1 of the Crack program is an attempt to extend the features
introduced in v4.0 and provide hooks for external libraries such as
Michael Glad's wonderful
.B UFC
crypt() implementation, which (on some platforms) can outperform my
fcrypt() by a factor of 3.  I have also been burdened with the task of
making Crack's memory handling bombproof (hah!) in the vague hope that
it will survive running out of memory on small machines.\**
.FS
- or even on large ones. Brian Tompsett at Hull tweaked Crack v3.3
until it could run to completion after filling the swapspace on each of a
network of SparcStation2's. Due to restructuring work on v4.0, I have
had to write my own sorting algorithm & re-implement all of his tweaks
from scratch, and can only hope that I have emulated the bombproofness
of this desirable (?) functionality.
.FE
.LP
The extensions that I mention above regard the addition of extra
primitives to the dictionary processing language which permit the
production of more concise dictionaries containing words, more of which
are likely to be passwords.  The idea is to gain efficiency by removing
some of the dross from the generated dictionaries. 
.LP
Crack should (generally) be more disk-space efficient now that the
program can spot dictionaries which have been compressed using
.I compress
or
.I pack
and will uncompress them on the fly as necessary (using
.I zcat
or
.I pcat 
respectively).\**
.FS
Note to people who are short on memory or swap: do remember that to do
this Crack will have to
.I fork()
(via
.I popen() )
and might not be able to create the uncompressing process.  Hence, if
you intend to swaplock your machine, don't compress the dictionaries. 
Switch this off by editing the
.C Crack
shellscript.
.FE
.NH 1
Crack Methodology - Part 1: Internals
.LP
Crack takes as its input a series of password files and source
dictionaries.  It merges the dictionaries, turns the password files into
a sorted list, and generates lists of possible passwords from the merged
dictionary or from information gleaned about users from the password
file. 
It does
.B not
attempt to remedy the problem of allowing users to have guessable
passwords, and it should
.B NOT
be used in place of getting a really good, secure
.C passwd
program replacement.\**
.FS
See the end of ths document for more information about
.I passwd
replacements.
.FE
.LP
The above paragraphs define the purpose of Crack, and embody a great
deal of hard work, screams of
.I Eureka! ,
drunkeness, and a fair amount of swearing too.  There is a lot
of thinking, philosophy, and empirical guesswork behind the way that
Crack attacks password files, and although it is not perfect, I
certainly hope that Crack will out-do most of it's competitors.
.LP
Crack works by making many individual passes over the password entries
that you supply to it.  Each pass generates password guesses based upon
a sequence of rules, supplied to the program by the
user. The rules are specified in a simplistic language in the files
.C gecos.rules
and
.C dicts.rules ,
to be found in the
.C Scripts
directory.
The distinction between these two files will be made clear later.
.LP
The rules are written as a simple string of characters, with one rule to
a line.  Blank lines, and comment lines beginning with a hash character
.B #
are ignored.  Trailing whitespace is also ignored.  The instructions in
the rule are followed from left to right, and are applied to the
dictionary words one by one, as the words are loaded.  Some simple
pattern matching primitives are provided for selection purposes, so that
if the dictionary word does not match the pattern, it is ignored.  This
saves on time and memory.  Before carrying on, I suggest that you browse
through
.C Scripts/dicts.rules ,
take a look at the rules supplied as defaults, and try to work out what
they do. 
.LP
The rules are stored in two different files for two different purposes.
Rules in
.C Scripts/gecos.rules
are applied to data generated by Crack from the pw_gecos and pw_gecos
entries of the user's password entry.  The data fed to the gecos rules
for the user
.I "aem",
who is
.I "Alec David Muffett, Systems"
would be:
.I "aem",
.I "Alec",
.I "David",
.I "Muffett",
.I "Systems",
and a series of permutations of those words, either re-ordering the
words and joining them together (eg:
.I "AlecMuffett" ),
or making up new words based on initial letters of one word taken with
the rest of another (eg:
.I "AMuffett" ).\**
.FS
- and
.I ASystems
and
.I DSystems ,
and
.I MSystems ,
etc... because Crack does not differentiate. Hence, care should be
taken to check for redundancy when adding new rules, so as not to waste
time during the gecos pass.
.FE
.LP
The entire set of rules in gecos.rules is applied to each of these
words, which creates many more permutations and combinations, all of
which are tested.  Hence testing the password gecos information under
Crack v4.0 and upwards takes somewhat longer than previously, but it is
far more thorough. 
.sp 1v
.LP
After a pass has been made over the data based on gecos information,
Crack makes further passes over the password data using successive rules
from the
.C Scripts/dicts.rules
by loading the whole of
.C Dicts/bigdict
file into memory, with the rule being applied to each word from that
file.  This generates a
.I "resident dictionary" ,
which is sorted and uniqued so as to prevent wasting time on repetition. 
After each pass is completed, the memory used by the resident dictionary
is freed up, and (hopefully) re-used when the next dictionary is loaded. 
.LP
The
.C Dicts/bigdict
dictionary is created by Crack by merging, sorting, and uniq'ing the
source dictionaries, which are to be found in the directory
.C DictSrc
and which may also be named in the Crack shellscript, via the
.C $STDDICT
variable. (The default value of $STDDICT is
.C /usr/dict/words ).
.LP
The file
.C DictSrc/bad_pws.dat
is a dictionary which is meant to provide many of those common but
non-dictionary passwords, such as
.I 12345678
or
.I qwerty .
.LP
If you wish to provide a dictionary of your own, just copy it into the
.C DictSrc
directory (use 
.C compress 
on it if you wish to save space; Crack will unpack it whilst generating
the big dictionary) and then delete the contents of the
.C Dicts
directory by running
.C Scripts/spotless .
Your new dictionary will be merged in on the next run. For more
information on dictionary attacks, see the
.I excellent
paper called "Foiling the Cracker: A Survey of, and Improvements to,
Password Security" by Daniel Klein, available from
.I "ftp.sei.cmu.edu"
in
.I "~/pub/dvk/passwd.*" .
Also, please read the
.C APPENDIX
file supplied with this distribution.\**
.FS
Extra dictionaries (those detailed in Dan Klein's paper) can be
obtained via anonymous FTP from
.I ftp.uu.net
(137.39.1.9) as
.I ~/pub/dictionaries.tar.Z ;
or check an
.I Archie
database for other possible sources of dictionaries.
.FE
.LP
Having described the method of cracking, perhaps we should now
investigate the algorithm used to overlay the cracking mechanism.
.NH 1
Crack Methodology - Part 2: Feedback Filters
.LP
As is stated above, Crack permutes and loads dictionaries directly
into memory, sorts and uniques them, before attempting to use each of
the words as a guess for each users' password.  If Crack correctly
guesses a password, it marks the user as
.I done
and does not waste
further time on trying to break that users password.
.LP
Once Crack has finished a dictionary pass, it sweeps the list of users
looking for the passwords it has cracked. It stores the cracked passwords
in both plaintext and encrypted forms in a
.I "feedback file"
in the directory
.C Runtime .
Feedback files have names of the form
.C Runtime/F* .
.LP
The purpose of this is so that, when Crack is next invoked, it may
recognise passwords that it has successfully cracked before, and filter
them from the input to the password cracker. This provides an
.I instant
list of crackable users who have not changed their passwords since the
last time Crack was run. This list appears in a file with name 
.C out*
in the
.C $CRACK_OUT
directory, or on
.I stdout ,
if foreground mode is invoked (see
.I Options ,
below).
.LP
In a similar vein, when a Crack run terminates normally, it writes out
to the feedback file all encrypted passwords that it has
.B NOT
succeeded in cracking.  Crack will then ignore all of these passwords
next time you run it.
.LP
Obviously, this is not desirable if you frequently change your
dictionaries or rules, and so there is a script provided,
.C Scripts/mrgfbk
which sorts your feedback files, merges them into one, and optionally
removes all traces of 'uncrackable' passwords, so that your next Crack
run can have a go at passwords it has not succeeded in breaking before.
.LP
.C Mrgfbk
is invoked automatically if you run
.C Scripts/spotless .
.NH 1
Crack Methodology - Part 3: Execution and Networking
.LP
Each time Crack is invoked, whether networked or not, it generates a
.I diefile
with a name of the form
.C Runtime/D*
(for network cracks, this file is generated by RCrack, and is of the form
.C Runtime/DR*
which points to a
.B real
diefile, named
.C Runtime/RD* 
- see below for details).
.LP
These diefiles contain debugging information about the job, and are
generated so that all the jobs on the entire network can be called
quickly by invoking
.C Scripts/plaster .
Diefiles delete themselves after they have been run.
.LP
As you will read in the sections below, Crack has a
.C "-network"
option: This is designed to be a simple method of automatically
spreading the load of password cracking out over several machines on a
network, preferably if they are connected by some form of networked
filestore.
.LP
When
.C "Crack -network"
is invoked, it filters its input in the ordinary way, and then splits
its load up amongst several machines which are specified in the file
.C Scripts/network.conf .
.LP
This file contains a series of hostnames, power ratings, flags, etc,
relevant to the running of Crack on each machine.  Crack then calls
.C Scripts/RCrack
to use the
.C rsh
command (or similar) to invoke Crack on the other hosts.  See the RCrack
script, and the example network.conf file for details.
.NH 1
Installation
.LP
Crack is one of those most unusual of beasties, a self-installing
program.  Some people have complained about this apparent weirdness, but
it has grown up with Crack ever since the earliest network version, when
I could not be bothered to log into several different machines with
several different architectures, just in order to build the binaries. 
Once the necessary configuration options have been set, the executables
are created via
.C make
by running the Crack shellscript .
.LP
Crack's configuration lies in two files, the
.C Crack
shell script, which contains all the installation specific configuration
data, and the file
.C Sources/conf.h ,
which contains configuration options specific to various binary platforms.
.LP
In the Crack shellscript, you will have to edit the
.C CRACK_HOME
variable to the correct value.  This variable should be set to an
absolute path name (names relative to
.I ~username
are OK, so long as you have some sort of
.C csh )
through which the directory containing Crack may be accessed on
.B ALL
the machines that Crack will be run on. There is a similar variable
.C CRACK_OUT
which specifies where Crack should put its output files - by default,
this is the same as
.C "$CRACK_HOME" .
.LP
You will also have to edit the file
.C Sources/conf.h
and work out which switches to enable.  Each
.C #define
has a small note explaining its purpose.  Where I have been in doubt about
the portability of certain library functions, usually I have re-written
it, so you should be OK.  Let me know of your problems, if you have any.
.LP
If you will be using
.C "Crack -network"
you will then have to generate a
.C Scripts/network.conf
file. This contains a list of hostnames to
.C rsh
to, what their
.I "binary type"
is (useful when running a network Crack on several different
architectures), a guesstimate of their
.I "relative power"
(take your slowest machine as unary, and measure all others relative to
it), and a list of per-host
.I flags
to
.B add
to those specified on the
.C Crack
command line, when calling that host.  There is an example of such a
file provided in the Scripts directory - take a look at it.
.LP
If ever you wish to specify a more precise figure as to the relative
power of your machines, or you are simply at a loss, play with the
command
.C "make tests"
in the source code directory.  This can provide you with the number of
fcrypt()s that your machine can do per second, which is a number that
you can plug into your
.C network.conf
as a measure of your machines' power (after rounding the value to an
integer).
.NH 1
Usage
.LP
Okay, so, let's assume that you have edited your
.C Crack
script, and your
.C Sources/conf.h
file, where do you go from here ?
.LP
.DS B
.fi
.C Crack
[\c
.I options ]
[\c
.I bindir ]
.C /etc/passwd
[...other passwd files]
.sp 1v
.C "Crack -network"
[\c
.I options ]
.C /etc/passwd
[...other passwd files]
.DE
.LP
Where
.B bindir
is the optional name of the directory where you want the binaries
installed.  This is useful where you want to be able to run versions of
Crack on several different architectures. If
.B bindir
does not exist, a warning will be issued, and the directory created.
.QP
Note:
.B bindir
defaults to the name
.C generic
if not supplied.
.QP
.LP
.B "Notes for Yellow Pages (NIS) Users:"
I have occasional queries about how to get Crack running from a YP
password file.  There are several methods, but by far the simplest is to
generate a passwd format file by running:-
.DS B
.C "ypcat passwd > passwd.yp"
.DE
and then running Crack on this file.
.NH 1
Options
.IP "\fB-f\fP"
Runs Crack in
.I foreground
mode, ie: the password cracker is not backgrounded, and messages appear
on stdout and stderr as you would expect.  This option is only really
useful for very small password files, or when you want to put a wrapper
script around Crack.
.IP
Foreground mode is disabled if you try running
.C "Crack -network -f"
on the command line, because of the insensibility of
.C rsh ing
to several machines in turn, waiting for each one to finish before
calling the next. However, please read the section about
.I "Network Cracking without NFS/RFS" ,
below.
.IP "\fB-v\fP"
Sets verbose mode, whereby Crack will print every guess it is trying on
a per-user basis.  This is a very quick way of flooding your filestore,
but useful if you think something is going wrong.
.IP "\fB-m\fP"
Sends mail to any user whose password you crack by invoking
.C Scripts/nastygram
with their username as an argument.  The reason for using the script is
so that a degree of flexibility in the format of the mail message is
supplied; ie: you don't have to recompile code in order to change the
message.\**
.FS
I'm uncertain about the wisdom of mailing someone like this.  If someone
browses your cracked user's mail somehow, it's like a great big neon
sign pointing at the user saying "This Is A Crackable Account - Go For
It!".  Not to mention the false sense of security it engenders in the
System Manager that he's "informed" the user to change his password.
What if the user doesn't log on for 3 months? However, so many people
have wired it into their own versions of Crack, I suppose it
.B must
be provided... AEM
.FE
.IP "\fB-nvalue\fP"
Sets the process to be
.C nice() ed
to
.I value ,
so, for example, the switch
.C \&-n19
sets the Crack process to run at the lowest priority.
.IP "\fB-network\fP"
Throws Crack into network mode, in which it reads the
.C Scripts/network.conf
file, splits its input into chunks which are sized according to the
power of the target machine, and calls
.C rsh
to run Crack on that machine.  Options for Crack running on the target
machine may be supplied on the command line (eg: verbose or recover
mode), or in the network.conf file if they pertain to specific hosts
(eg:
.C nice()
values).
.IP "\fB-r<pointfile>\fP"
This is only for use when running in
.I recover
mode.  When a running Crack starts pass 2, it periodically saves its
state in a
.I pointfile ,
with a name of the form
.C "Runtime/P.*"
This file can be used to recover where you were should a host crash.
Simply invoke Crack in
.B exactly
the same manner as the last time, with the addition of the
.C "-r"
switch, (eg:
.C "-rRuntime/Pfred12345" )
switch.  Crack will startup and read the file, and jump to roughly where
it left off.  If you are cracking a very large password file, this can
save oodles of time after a crash.
.IP
If you were running a
.I network
Crack, then the jobs will again be spawned onto all the machines of the
original Crack.  The program will then check that the host it is running
on is the same as is mentioned in the pointfile.  If it is not, it will
quietly die.  Thus, assuming that you supply the same input data and do
not change your
.C network.conf
file, Crack should pick up where it left off.  This is a bit inelegant,
but it's better than nothing at the moment.
.IP
The method of error recovery outlined above causes headaches for users
who want to do multiprocessing on parallel architectures.  Crack is in
no way parallel, and because of the way it's structured (reading stdin
from shellscript frontends) it is a pain to divide the work amongst
several processes via
.C fork() ing.
.IP
The hack solution to get several copies of Crack running on one machine
with
.I n
processors at the moment is to insert
.I n
copies of the entry for your parallel machine into the
.C Scripts/network.conf
file. If you use the
.C \&-r
option in these circumstances however, you will get
.I n
copies of the recovered process running, only one of them will have the
correct input data.
.IP
The old solution to this problem (see old documentation if you are
interested) has been negated by the introduction of feedback mode, so
the best bet in this particular situation is to wait until the other
jobs are done (and have written out lists of uncrackable passwords), and
then re-start the jobs from scratch.  Anyone whose password was not
cracked on the first run will be ignored on the second, if they have not
changed it since.  This is inelegant, but it's the best I can do in the
limited time available.
.NH
Support Scripts
.LP
The
.C Scripts
directory contains a small number of support and utility scripts, some
of which are designed to help Crack users check their progress.
Briefly, the most useful ones are:-
.IP "\fBScripts/shadmrg\fP"
This is a small (but hopefully readable) script for merging
.C /etc/passwd
and
.C /etc/shadow
on System V style shadow password systems.  It produces the merged data
to stdout, and will need redirecting into a file before Crack can work
on it.  The script is meant to be fairly lucid, on the grounds that I
worry that there are many shadowing schemes out there, and perhaps not
all have the same data format.
.IP
.B "I have not"
wired this facility into the Crack command itself because the world does
.B NOT
revolve around System V yet, regardless of what some people would have
me believe, and I believe that the lack of direct support for NIS
outlined above, sets a precedent.  There are just too many
incompatibilities in shadow password schemes for me to hardwire
anything.
.IP "\fBScripts/plaster\fP"
which is named after a dumb joke, but is a simple frontend to the
.C "Runtime/D*"
diefiles that each copy of the password cracker generates. Invoking
.C Scripts/plaster
will kill off all copies of the password cracker you are running, over
the network or otherwise.
.IP "\fBScripts/status\fP"
This script
.C rsh es
to each machine mentioned in the
.C Scripts/network.conf
file, and provides some information about processes and uptime on that
machine.  This is useful when you want to find out just how well your
password crackers are getting on during a
.C "Crack -network" .
.IP "\fBScripts/{clean,spotless}\fP"
These are really just frontends to a makefile. Invoking
.C Scripts/clean
tidies up the Crack home directory, and removes probably unwanted files,
but leaves the pre-processed dictionary
.C bigdict
intact.
.C Scripts/spotless
does the same as
.C Scripts/clean
but obliterates
.C bigdict
and old output files too, and compresses the feedback files into one.
.IP "\fBScripts/nastygram\fP"
This is the shellscript that is invoked by the password cracker to send
mail to users who have guessable passwords, if the
.C -m
option is used. Edit it at your leisure to suit your system.
.IP "\fBScripts/guess2fbk\fP"
This script takes your
.C out*
files as arguments and reformats the 'Guessed' lines into a slightly
messy
.I feedback
file, suitable for storing with the others.
.IP
An occasion where this might be useful is when your cracker has guessed
many peoples passwords, and then died for some reason (a crash?) before
writing out the guesses to a feedback file.  Running
.DS B
.C "Scripts/guess2fbk out* >> Runtime/F.new"
.DE
will save the work that has been done.
.NH 1
Network Cracking without NFS/RFS
.LP
For those users who have some form of
.C rsh
command, but do not have a a networked filestore running between hosts,
there is now a solution which will allow you to do networked cracking,
proposed to me by Brian Tompsett at Hull.  Personally, I consider the
idea to be potty, but it fills in missing functionality in a wonderfully
tacky manner.
.LP
From the documentation above, you will note that Crack will undo the
.C "-f"
.I "(output in foreground)"
option, if it is invoked with the
.C "-network"
switch at the same time (see the
.I Options
section above).  This is true, but it does not apply if you specify
.C "-f"
option in the
.C network.conf
file.
.LP
The practical upshot of doing this is that remote copies of Crack
can be made to read from
.I stdin
and write to
.I stdout
over a network link, and thus remote processing is accomplished.  I have
tweaked Crack in such a way, therefore, that if the
.C "-f"
option is specified amongst the crack-flags of a host in the
network.conf, rather than backgrounding itself on the remote host, the
.C rsh
command on the
.B server
is backgrounded, and output is written directly to the files on the
server's filestore.
.LP
There are restrictions upon this method, mostly involving the number of
processes that a user may run on the server at any one time, and that
you will have to collect feedback output together manually (dropping it
into the
.C Runtime
directory on the server).  However, it works. Also, if you try to use
.C rsh
as another user, you will suffer problems if
.C rsh
insists on reading something from your terminal (eg: a password for the
remote account).  Also, recovering using checkpointing goes out the
window unless you specify the name of the pointfile as it is named
on the remote machine.
.NH 1
UFC Support and notes on fast crypt() implementations
.LP
The stdlib version of the
.C crypt()
subroutine is incredibly slow.  It is a
.I massive
bottleneck to the execution of Crack and on typical platforms that you
get at universities, it is rare to find a machine which will achieve
more than 50 standard crypt() s per second.  On low-end diskless
workstations, you may expect 2 or 3 per second.  It was this slowness of
the crypt() algorithm which originally supplied much of the security
Unix needed.\**
.FS
See: "Password Security, A Case History" by Bob Morris & Ken Thomson, in
the Unix Programmer Docs.
.FE
.LP
There are now
.B many
implementations of faster versions of crypt()
to be found on the network.  The one supplied with Crack v3.2 and
upwards is called
.C fcrypt() .
It was originally written in May 1986 by Robert Baldwin at MIT, and is a
good version of the crypt() subroutine.  I received a copy from Icarus
Sparry at Bath University, who had made a couple of portability
enhancements to the code.
.LP
I rewrote most of the tables and the KeySchedule generating algorithm in
the original
.I fdes-init.c
to knock 40% off the execution overhead of fcrypt() in the form that it
was shipped to me.  I inlined a bunch of stuff, put it into a single
file, got some advice from Matt Bishop and Bob Baldwin [both of whom I
am greatly indebted to] about what to do to the
.C xform()
routine and to the fcrypt function itself, and tidied up some
algorithms.  I have also added more lookup tables and reduced several
formula for faster use.  Fcrypt() is now barely recognisable as being
based on its former incarnation, and it is 3x faster.
.LP
On a DecStation 5000/200, fcrypt() is about 16 times faster than the
standard crypt (your mileage may vary with other architectures and
compilers).  This speed puts fcrypt() into the "moderately fast" league
of crypt implementations. 
.LP
Amongst other crypt implementations available is
.B UFC
by Michael Glad.  UFC-crypt is a version of the crypt subroutine which
is optimised for machines with 32-bit long integers and generally
outperforms my fcrypt() by a factor of between 1 and 3, for a tradeoff
of large memory usage, and memory-cache unfriendliness.  Hooks for even
more optimised assembler versions of crypt() are also provided for some
platforms (Sun, HP, ...).  Getting UFC to work on 16 bit architectures
is nearly impossible.
.LP
However, on most architectures, UFC generates a stunning increase in the
power of Crack, and so, from v4.1 onwards, Crack is written to
automatically make use of UFC if it can find it.  All that you have to
do is to obtain a suitable copy of UFC (preferably a version which
mentions that it is compatible with
.C "Crack v4.1" ,
and unpack it into a directory called
.C ufc-crypt
in
.C $CRACK_HOME ,
and then delete your old binaries.  UFC will then be detected, compiled,
tested and used in preference to fcrypt() by the Crack program, wherever
possible.
.NH 1
Conclusions
.LP
What can be done about brute force attacks on your password file ?
.LP
You must get a drop-in replacement for the
.C passwd
and
.C yppasswd
commands; one which will stop people from choosing bad passwords in the
first place.  There are several programs to do this; Matt Bishop's
.C "passwd+"
and Clyde Hoover's
.C "npasswd"
program are good examples which are freely available.  Consult an
.B Archie
database for more details on where you can get them from.
.LP
It would be nice if an organisation (such as
.B CERT ?)
could be persuaded to supply skeletons of
.I sensible
passwd commands for the public good, as well as an archive of security
related utilities\**
on top of the excellent
.C COPS .
.FS
.C COPS
is available for anonymous FTP from
.I "cert.sei.cmu.edu"
(128.237.253.5) in
.I ~/cops
.FE
However, for Unix security to improve on a global scale, we will also
require pressure on the vendors, so that programs are written correctly
from the beginning.
DataMuseum.dk

DKUUG/EUUG Conference tapes

⟦38981e8a7⟧ TextFile

Derivation

TextFile
