|
Softpanorama
(slightly skeptical)
Open Source Software Educational Society |
May the
source be with you,
but remember the KISS principle ;-)
|
Password Checkers/Crackers
First and foremost, not too much zeal
Talleyrand advice to young diplomats
The power of password crackers is over hyped. In real life unless you
manage to steal the shadow file from some server, it's impossible to apply
cracker to the system. But in order to read shadow file you usually need to be
root or to have a physical access to the server (and a possibility to reboot
it). In both cases it's unclear why one need to crack passwords on the
server that as already penetrated, unless the goal is to reuse them for
attacking other servers.
The primary legitimate
purpose of Unix password crackers is to detect and
eliminate weak user passwords but even this task is dubious: if system is
configured to disable account, say for an hour after three unsuccessful attempts,
then
even weak password can withstand most of the attacks. But still due diligence is not a
bad strategy.
It's important to understand that "realistic" cracking scenario requires access to the password hashes
and a very fast computer. In most modern Unix systems (UP-UX is a notable
exception) shadow files that contain password hashes are readable only by the root user.
In a way introduction of shadow files devalued the importance of crackers. Still
if hashes can be intercepted (for example if NIS is used) crackers can be used
against them.
Length of password is very important: longer passwords usually cannot be cracked in a reasonable time.
Brute force attack on password longer then 8 characters is rarely successful,
especially if AOL scheme of generating long password using two short words with
one of several delimiters between them. That's why
it makes sense to enforce practices that help to create stronger passwords and
first of all to limit the minimal password length to at least 8, This is
especially important for root passwords.
For the same reason it is important to mix upper and lower cases in password:
that's double alphabet size and for the 8 character passwords makes brute force
attack approximately 256 times longer (2^8). That's why enforcing usage of at
least one digit, mixed case and delimiters in the password is so important for
root passwords. But again unless hashes are stolen brute force attack is
impossible with modern limitation on the number of failed attempts. So it is an
interesting theme for theoretical discussion not so much for practice.
But this terrain should be navigated with extreme caution. It is very easy to
go overboard with this and excessive zeal backfires. Naive Unix
administrators who after reading some superficial security book try to enforce a
Draconian schemes of unsuspecting users (random passwords or too complex
password schemes) usually weaken the security due to unanticipated side effects
of such actions.
If you're looking for a way to
recover or bypass a lost password, it's usually easier just change it or ask
your system administrator to do so. If it's the administrator (root) password
that is lost, there's almost always a way to bypass OS security by booting from
CD and change it after mounting the filesystem (the exact details are depends on Unix flavor.
For Solaris the procedure can be found at
Solaris root
password recovery.) The
most complex situation is if the archive (zip or rar) or Microsoft document or spreadsheet is
encrypted and password is lost. Here you need to work two ways:
- Check if there are weaknesses in encryption used.
- Modify the cracker to generate set of passwords based on some ideas
about what the password can be from the user who lost the password. For example you can
concatenate dynamic suffixes
that are often used by system administrators for generating the initial
password from several "core" prefixes that are often used by system
administrators in large companies. For example if the company name is ABC, then you
can try ABC123, ABC1234, myABC, etc. Knowledge of lower and upper
limits on length and composition (for example whether the upper case
characters were used) can also help.
Old Unixes use DEC-based hashing and password are limited to just 8 characters,
which is a major disadvantage. Better,
MD5-based hashes that permits passwords longer then 8 characters originated in
FreeBSD are now also used in Linux and Solaris 10.
In this case
it is strongly recommended that users switched to "AOL scheme": two short words
connected with some delimiter (:, -, /, etc). Like
faKe43-secuR55.
There are two major cracker implemetations:
Crack by Alec Muffett
Unix, free (Perl Artistic License). Here is how it is characterized at
Unix Password Crackers
page of
Openwall Project project
Crack is the classical Unix password
cracker. The distribution includes Eric Young's fcrypt, - an
implementation of the traditional DES-based Unix password hashing (quite
efficient, yet typically several times slower than what John the Ripper
is able to achieve).
When generating candidate passwords to try, Crack will use
information from the password files and wordlists with word mangling
rules.
One feature specific to Crack is its DAWG (Directed Acyclic Word
Graphs) wordlist compression, which saves disk space needed to store
wordlists.
John the Ripper
Licensed under GPL
v2. Here is how it is characterized at
Unix Password Crackers
of
Openwall Project
John the Ripper is a fast password cracker,
currently available for many flavors of Unix (11 are officially
supported, not counting different architectures), DOS, Win32, BeOS, and
OpenVMS. Besides the crypt(3) password hash types most commonly found on
various Unix flavors (several DES-based, MD5-based, and
Blowfish-based), supported
out of the box are Kerberos AFS and Windows NT/2000/XP LM hashes.
John uses efficient special-purpose cryptographic algorithms (such as
bitslice DES) and
implementations (including in assembly, making use of MMX on x86
processors).
Four cracking modes are implemented: "single crack" (derives
candidate passwords to try from information in the password files
themselves), wordlist with word mangling rules, "incremental mode"
(tries all possible character combinations in an optimal order based on
statistical information), and external (allows you to program an
algorithm in a C-like language).
There are
contributed patches which add support for OpenVMS passwords
(SYSUAF.DAT), Windows NT/2000/XP NTLM (MD4-based) hashes, S/Key skeykeys
files, AFS/Kerberos v4 TGT, Kerberos v5 TGT, Netscape LDAP server (SHA,
SSHA) passwords, MySQL passwords, Eggdrop IRC bot userfiles, Apache
MD5-based "apr1" password hashes, and raw MD5 hashes (hex-encoded).
An implementation of one of the modern password hashes found in John
is also available separately
for use in your software or on your servers.
One of the few useful application of crackers is their usage as a proactive password
strength checking module for PAM-aware password changing programs.
Notes:
- Those pages are written by people for whom English is not a
native language. Some amount of grammar and spelling errors
should be expected.
- This is a Spartan WHYFF (We Help You For Free) site. It
cannot replace the best teachers and
the
best books.
- The site contain some obsolete pages as it develops like a
living tree... Some links on older pages
are broken. Please
try to use Google, Open directory, etc. to find a replacement link
(see
HOWTO search the WEB for details).
We would appreciate if you can
mail us a correct link.
|
|
Maximum Security -- Ch
10 -- Password Crackers
Been Cracked Just Put PAM On It!
The pam_cracklib
Module
The
pam_cracklib module is
intended to work only with the
password module type. It's purpose is to check a password for
strength and for length, both elements being
configurable with arguments described below. This module
functions only in a stack, since it has no updating
capabilities. It requires the
libcrack library and the cracklib_dict Crack dictionary, both of which are found in
/usr/lib of the Red Hat 5.2/6.0 distribution. As you can see, this
module depends heavily on elements of the Crack utility,
which is discussed in Chapter 12.
The flexibility of
PAM is evidenced by the fact that this is not the only
password strength checking PAM module. Another is
pam_passwd+, which is available at
http://www.us.kernel.org/pub/linux/libs/pam/modules.html
The arguments
available to pam_cracklib are described in Table 5.5.
Table 5.5
Arguments for pam_cracklib
| Argument |
Description |
|
debug |
This argument writes
additional module behavior information to
syslog, but does not log passwords. |
|
type=STRING
|
This argument replaces the
string UNIX with STRING in the messages it generates, such as
New UNIX password:. |
|
retry=n |
This is the number of retries this module allows a user
when changing a password. The default is 1. |
|
difok=n |
This represents the number of characters in the new
password that must be different from the old
password. The default is 10. Regardless of this
limit, however, any new password that has at
least half the characters different from the old
will be accepted. |
|
minlen=n |
This argument specifies the
minimum password length + 1. By default it is
set to 9 which means the minimum password length
is actually 10. To further confuse the issue,
this minimum length may actually be reduced
depending upon the values specified for the
*credit parameters listed below. |
|
lcredit=n |
The value specified here is
the number of characters by which the
minlen value is reduced by virtue of having at least one
lowercase character in the new password. The
default is 1. Can be set to 0 to eliminate the
credit. |
|
ucredit=n |
The value specified here is
the number of characters by which the
minlen value is reduced by virtue of having at least one
uppercase character in the new password. The
default is 1. Can be set to 0 to eliminate the
credit. |
|
dcredit=n |
The value specified here is
the number of characters by which the
minlen value is reduced by virtue of having at least one
numeric character in the new password. The
default is 1. Can be set to 0 to eliminate the
credit. |
|
ocredit=n |
The value specified here is
the number of characters by which the
minlen value is reduced by virtue of having at least one
nonalpha-numeric character in the new password.
The default is 1. Can be set to 0 to eliminate
the credit. |
In addition to the
configurable options in Table 5.5, the
pam_cracklib
checks the new password for strength
by
- Verifying that the
new password is not the reverse of the old password.
- Verifying that the
new password is not a simple case change of some
characters of the old password.
- Checking if
the new password is in the
cracklib_dict. If it is, it warns the user but does not force another
password choice.
The Effect of
Stacking pam_pwdb and pam_cracklib For Module Type
password
In this section, we will take a look
at how pam_cracklib interacts with pam_pwdb in the stack shown in Example 5-3 on page 86.
Recall that in
Example 5-3 the two stacked entries appeared in
/etc/ pam.d/passwd.
Password required /lib/security/pam_cracklib.so retry=3
Password required /lib/security/pam_pwdb.so use_authtok
The first entry
invokes pam_cracklib and prompts the user for his or her new password (remember
that the auth module type pam_pwdb entry is responsible for prompting the user for his or her
old password, for authentication). After the user
has supplied the new password,
pam_cracklib requests that it be repeated for verification. Once
completed, pam_cracklib performs its checks to see if the password is acceptable. If
so, it passes the new password to
pam_pwdb
which has the
use_authtok argument meaning it will accept this new password and
request the pwdb library to update the appropriate database.
Let's take a look
at the power and flexibility of these modules by
considering an example. Suppose that we would like to
use md5 instead of the standard UNIX
crypt(3) mechanism for
hashing purposes. This is a good idea, because popular
password-guessing tools like Crack require significantly
more CPU resources to guess passwords (see The White
Hat Use of Crack on page 337). The major benefit of
using md5 is that you can require longer passwords—20, 30, or even
more characters. Let's look at an example requiring
20-character passwords. We'll also set the
type
argument to see if our users are paying attention.
Example 5-5 shows what the stack might look like if we
impose these changes in
/etc/pam.d/passwd.
Example 5-5 Using
md5 and minlen in
/etc/pam.d/passwd
Password required /lib/security/pam_cracklib.so minlen=20\
retry=3 type=SECRET
password required /lib/security/pam_pwdb.so md5 use_authtok
WARNING
If you make
changes similar to what is shown in Example 5-5, you
must also change all equivalent instances of
pam_pwdb and pam_cracklib using module type password. In Red Hat 5.2, this would
minimally include the files
chfn, chsh, login, rlogin, su, and xdm in /etc/pam.d.
Now that we have
made these changes, let's see what happens to the user,
mary, when she tries to change her password in Example 5-6. She
is offered three opportunities to select a password.
This is due to the retry=3
argument to
pam_cracklib (see Example 5-5 on page 91). Actually, it appears that Mary
is attempting to make good password choices.
Unfortunately she doesn't know about the changes to PAM
and therefore doesn't know that she needs to choose a
longer password. So you, being the responsive
administrator, inform her that she needs to use a
20-character password. "What?!" she replies. And you
gently tell her that she can use a passphrase. Happy
now, she goes about her task (Example 5-7).
Example 5-6 Unsuccessful
Password Change
$passwd
Changing password for mary
(current)UNIX password:j3n#Ky
New SECRET password:Rt!72g
BAD PASSWORD:is too simple
New SECRET password:8x@$iI
BAD PASSWORD:is too simple
New SECRET password:P5-+yh
BAD PASSWORD:is too simple
New SECRET password:8x@$iI
passwd:Authentication token manipulation error
$
Example 5-7 Successful
Password Change
$passwd
Changing password for mary
(current)UNIX password:j3n#Ky
New SECRET password:I need a #%$3+raise
Retype new SECRET password:I need a #%$3+raise
passwd:all authentication tokens updated successfully
$
Notice that the
message displayed by
pam_cracklib contains our
type entry, New SECRET
password:. This change
does not appear in the message from
pam_pwdb—(current) UNIX password:—because pam_pwdb does not support the type argument.
Linux-PAM modules etc. page
- Password strength checking modules
- Etc
- pam_abl
- Andy Armstrong recommends a module to
automatically
blacklist hosts from which large numbers of failed login
attempts originate.
- pam_shells: authenticate users if their shell is listed
in the /etc/shells file.
Erik Troan <ewt at redhat.com>
- pam_wheel: for enforcing the wheel group privileges;
Cristian Gafton <gafton at redhat.com>
Red Hat Password Security
To protect the network from intrusion it is a good idea for
system administrators to verify that the passwords used within
an organization are strong ones. When users are asked to create
or change passwords, they can use the command line application
passwd, which is
Pluggable Authentication Manager (PAM)
aware and will therefore check to see if the password is easy to
crack or too short in length via the
pam_cracklib.so PAM module. Since PAM is customizable, it
is possible to add further password integrity checkers, such as
pam_passwdqc (available from
http://www.openwall.com/passwdqc/) or to write your own
module. For a list of available PAM modules, see
http://www.kernel.org/pub/linux/libs/pam/modules.html. For
more information about PAM, see the chapter titled
Pluggable Authentication Modules (PAM)
in the Red Hat Linux Reference Guide.
ONLamp.com Cracking
Passwords to Enhance Security
In last week's article, we looked at which parts of a password policy
could be implemented by editing the /etc/login.conf file on your
FreeBSD system. This week, I want to look at some techniques that can be used
to implement the rest of our sample policy.
By editing /etc/login.conf, we were able to enforce a minimum
password length and set an expiry date on passwords. While it does not
enforce password lockout per se, your FreeBSD system does come with some
built-in mechanisms that make it harder for a person to try to guess a
password by repeatedly typing in different passwords.
Use your ALT Function keys to find a terminal with a login prompt. Let's
log in as a user, but type in an incorrect password:
login: bogus
Password:
Login incorrect
login:
Notice what happened here. When you typed in the password, none of your
keystrokes were displayed to your screen; this is to help prevent passersby
from noticing what password you are typing. Also, the "login incorrect" error
message doesn't specify what is incorrect. That is, it won't tell you if the
problem is an incorrect username or an incorrect password.
Since we were just given the login prompt back after the error message,
let's keep trying to use an incorrect password. At your fourth bad attempt,
you'll notice something different: it took a few seconds to get the login
prompt back. At your fifth bad attempt, it should take about 6 seconds before
you get your prompt back; at your sixth bad attempt, it should take about 9
seconds, and so on. This cycle will continue until you either have 10 bad
attempts or you use up 300 seconds. At that point, your screen should look
something like this:
FreeBSD/i386 (hostname) (ttyv4)
login:
and the cycle starts all over again.
While you were making your bad password attempts, your FreeBSD system was
keeping track of your actions. Use your ALT F1 keys to go to the console
terminal; you should see messages similar to this:
Jan 14 9:43:23 hostname login: 8 LOGIN FAILURES ON ttyv4
Jan 14 9:44:52 hostname login: 2 LOGIN FAILURES ON ttyv4
To implement the rest of our sample password policy, we'll have to be a
bit more creative. We wanted users to have at least one non-letter character
in their password, not be allowed to use their username as their password,
and not reuse any of their last ten passwords.
One way to accomplish this is to make users aware of the password policy,
then use a utility that will tell you which users are selecting poor
passwords. This method makes the users responsible for choosing passwords
that follow the policy, and makes the administrator responsible for ensuring
that the policy is being enforced.
But how can a utility view a user's password? Remember that passwords are
not stored anywhere on your FreeBSD system. Instead, a hash is stored in the
password database, and these hashes are in an encrypted format. Let's take a
minute to define what a hash is and how it is created.
A hash is a string of characters, like a password, that has been scrambled
by an encryption algorithm. That is, some form of complicated math was done
on the string of characters to make it very hard to guess what the original
string of characters was. As an example, one could apply an algorithm to the
word "password" and end up with something like
"$1$hnH/w50a$tPdv5HZRsDP46FtsW8eXH."
Good hashes contain something called a "salt." A salt is a set of random
characters that are added to the original string of characters before they
are encrypted. A simple example of a salt would be to add the time of day;
for example, if I log in at 8:45 using the password "password," the string
that would be encrypted could be "8pass45word." By adding this bit of
randomness to the password, my hash will actually be different every time I
log in, unless the only time I ever log in is at 8:45.
Whether a salt is used and what the salt actually is depends upon the
operating system and the encryption algorithm being used. On your FreeBSD
system, there is a function called crypt that uses either the
"DES" or the "MD5" encryption algorithms to encrypt passwords. If you're
curious to see the technical details on how crypt works, read
man 3 crypt. Don't be dismayed if you can't understand
everything in this manpage; encryption is supposed to be cryptic. Also, don't
confuse the utility crypt(1) with the function crypt(3).
The utility is a very primitive way to encrypt data files, while the function
is an elaborate mechanism used to create password hashes.
By definition, password hashes are "one-way" hashes. This means that if I
apply the same encryption algorithm to the hash, I won't end up with the
original password; instead, I'll just end up with a more scrambled hash. The
only way to find the original password is to type in a password, encrypt it
with the same algorithm, and compare the resultant hash. If the hash is
different, I must have used the wrong password; if the hash is the same, I
can assume that I've typed in the correct password.
Which brings us to password crackers. These are utilities that encrypt
hundreds of thousands of passwords in order to compare the resulting hashes
with the hashes in your password database. Password crackers do follow a
certain logic as they'll try the most common passwords first; for example,
they'll try the user's name forwards, backwards, and with a number, they'll
try information in the user's GECOS field, and they'll try a list of common
passwords such as "password" and "pass." Then they'll go through all of the
words in the dictionary. Not surprisingly, these types of crackers are called
"dictionary" password crackers. Some password crackers are called
"brute-force" password crackers as they add a third step: they'll patiently
try every keystroke combination possible until all the passwords have been
cracked.
Let's demonstrate using a dictionary password cracker to determine if the
passwords your users are selecting conform to your password policy. We'll
build and use the port called "Crack." As the superuser and while connected
to the Internet, type:
cd /usr/ports/security/crack
make install clean
Once the port is installed, remain as the superuser; cracking the contents
of the password database is definitely an exercise that requires superuser
privileges.
cd /usr/local/crack
ls -l
total 95
drwx------ 9 root wheel 512 Jan 13 15:45 ./
drwxr-xr-x 23 root wheel 512 Jan 13 20:26 ../
-rwx------ 1 root wheel 10788 Dec 20 1996 Crack*
-rw------- 1 root wheel 6415 Dec 20 1996 LICENCE
-rw------- 1 root wheel 1444 Dec 20 1996 Makefile
-rwx------ 1 root wheel 1792 Dec 13 1996 Reporter*
drwx------ 2 root wheel 1024 Jan 13 15:45 conf/
drwx------ 5 root wheel 512 Nov 4 1996 dict/
drwx------ 2 root wheel 512 Dec 20 1996 doc/
drwx------ 2 root wheel 512 Dec 19 1996 extra/
-rw------- 1 root wheel 33251 Dec 20 1996 manual.html
-rw------- 1 root wheel 31320 Dec 20 1996 manual.txt
drwx------ 4 root wheel 512 Jan 13 15:53 run/
drwx------ 2 root wheel 512 Dec 20 1996 scripts/
drwx------ 5 root wheel 512 Jan 13 15:45 src/
Notice the restrictive set of permissions given to this directory and its
contents; regular users won't be able to even cd into or view
the contents of this directory.
To run the password cracker, type:
./Crack -fmt bsd /etc/master.passwd
and you should see something similar to this:
Crack 5.0a: The Password Cracker.
(c) Alec Muffett, 1991, 1992, 1993, 1994, 1995, 1996
System: FreeBSD genisis 4.2-RELEASE FreeBSD 4.2-RELEASE #0: Tue Dec 12
20:01:29 EST 2000 genisis@genisis:/usr/src/sys/compile/SOUND i386
Home: /usr/local/crack
Invoked: ./Crack -fmt bsd /etc/master.passwd
Stamp: freebsd-4-i386_
Crack: making utilities in run/bin/freebsd-4-i386_
find . -name "*~" -print | xargs -n50 rm -f
( cd src; for dir in * ; do ( cd $dir ; make clean ) ; done )
rm -f dawglib.o debug.o rules.o stringlib.o *~
/bin/rm -f *.o tags core rpw destest des speed libdes.a .nfs* *.old *.bak
destest rpw des speed
rm -f *.o *~
`../../run/bin/freebsd-4-i386_/libc5.a' is up to date.
all made in util
Crack: The dictionaries seem up to date...
Crack: Sorting out and merging feedback, please be patient...
Crack: Merging password files...
cat: run/F-merged: No such file or directory
Crack: Creating gecos-derived dictionaries
mkgecosd: making non-permuted words dictionary
mkgecosd: making permuted words dictionary
Crack: launching: cracker -kill run/Kgenisis.22226
Done
On my system, the entire exercise was finished within 5 seconds. Now,
let's take a look at the results:
./Reporter -quiet
---- passwords cracked as of Sun Jan 14 12:17:41 EST 2001 ----
979492604:Guessed dlavigne [dlavigne] Dru Lavigne,,123-4567 [/etc/master.passwd
/bin/tcsh]
979492611:Guessed genisis [genisisgenisis] User & [/etc/master.passwd /bin/csh]
---- done ----
Hmmmm. Looks like I'll be having a talk with the users dlavigne and
genisis to remind them of our password policy. The password for "dlavigne" is
the same as the username [dlavigne]. The user "genisis" picked a nice long
password, but it is only the username twice: [genisisgenisis].
I'll have the user dlavigne change her password. One method of creating
nonsense passwords is to use the first letter of each word in a song and
throw some symbols or numbers into the mix; just remember not to hum the song
while you are typing it in. Using the song "We All Live in a Yellow
Submarine," dlavigne created the password "waliays87." Let's see what happens
when I rerun the Crack utility:
./Crack -fmt bsd /etc/master.passwd
./Reporter -quiet
---- passwords cracked as of Sun Jan 14 12:23:42 EST 2001 ----
979492611:Guessed genisis [genisisgenisis] User & [/etc/master.passwd /bin/csh]
---- done ----
It looks like the new password for "dlavigne" survived the dictionary
crack, as it no longer shows up in the output. If you run the Crack utility
and don't receive any output in the report, you can assume that your users
are choosing passwords that aren't simply some combination of their name or a
word that can be found in a dictionary; that is, they must be choosing some
random combination of numbers, letters, and symbols.
When Crack is run, it places its working files in the run directory; these
files will end with an extension that was the PID of the Crack process. After
you are finished using Crack, you should clean up this working directory by
typing:
make tidy
from the /usr/local/crack directory. It is also a good idea
to manually delete the run/F-merged file, as it contains the
results that were read by the Reporter utility:
more run/F-merged
F:$1$ZQQGAmIW$jCPUT9KjRGbXR/IpF0M/E0:genisisgenisis
F:pZV8Ju.2sEqsY:dlavigne
Notice that it shows the encrypted hash followed by the cracked password,
which is pretty sensitive information to leave on hard disk.
rm run/F-merged
One last note on running Crack: NEVER run any type of password cracker on
any computer that is not in a network that you are responsible for. It is
perfectly acceptable to enforce password policy on your network; it is
illegal to try to discover the passwords in use on another person's network.
Let's compare the dictionary cracker to a brute-force cracker. As the
superuser and while connected to the Internet, type:
cd /usr/ports/security/john
make install clean
Once it's finished building:
cd /usr/local/share/john
unshadow /etc/passwd /etc/master.passwd > passwd.1
john passwd.1
At this point, you'll lose your prompt for a long period of time; if you
use the top command to see what your CPU is doing, you'll notice
that most of your cpu cycles are being used by the brute-force cracker. Given
enough time, "john" will be able to crack every single hash in the password
database.
top -d1
last pid: 94308; load averages: 5.72, 5.82, 5.52 up 9+20:40:37 13:54:35
35 processes: 6 running, 25 sleeping, 4 zombie
Mem: 61M Active, 11M Inact, 22M Wired, 4380K Cache, 22M Buf, 23M Free
Swap: 260M Total, 260M Free
PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
94228 root 62 0 1276K 836K RUN 1:31 18.65% 18.65% john
78070 root 63 0 9120K 8748K RUN 13:53 18.55% 18.55% cracker
36951 root 63 0 9160K 8776K RUN 17:25 17.72% 17.72% cracker
15408 root 64 0 9160K 8776K RUN 18:54 17.53% 17.53% cracker
22467 root 62 0 9160K 8776K RUN 18:10 16.65% 16.65% cracker
47788 root 2 0 884K 440K select 0:30 0.00% 0.00% moused
14767 root 2 0 2196K 1232K select 0:08 0.00% 0.00% fetchmail
47768 root 2 0 2496K 1432K select 0:08 0.00% 0.00% sendmail
71556 root 2 0 5200K 3888K select 0:07 0.00% 0.00% perl
47767 root 10 0 924K 540K nanslp 0:05 0.00% 0.00% lpd
47761 root 10 0 964K 620K nanslp 0:04 0.00% 0.00% cron
47736 root 2 0 916K 540K select 0:04 0.00% 0.00% syslogd
47712 root 2 0 532K 220K select 0:03 0.00% 0.00% dhclient
47772 root 2 0 2092K 984K select 0:01 0.00% 0.00% sshd
47759 root 2 0 1048K 660K select 0:01 0.00% 0.00% inetd
47812 genisis 18 0 1328K 632K pause 0:01 0.00% 0.00% csh
14573 root 18 0 1348K 840K pause 0:01 0.00% 0.00% csh
47814 genisis 18 0 1340K 736K pause 0:01 0.00% 0.00% csh
We've stumbled upon some interesting points in this exercise. First, there
is no ethical reason to run a brute-force cracker on your FreeBSD machine.
The administrator's job is to enforce sensible passwords, not to know the
passwords used by his users. A utility such as Crack is sufficient to let the
administrator know which users are using passwords that can be guessed within
a few seconds by a dictionary password cracker.
However, the administrator does need to be aware that brute-force crackers
are easily and freely available on the Internet. Fortunately, before a user
can use a brute-force cracker, they need to have physical access to the
password databases; notice that we had to unshadow both password
databases into a file before we could run the john utility. It
is the responsibility of the system administrator to ensure that only
authorized, trusted users have access to the actual password database files
and any backups that contain the password databases.
Let's summarize what we've learned so far about password policies.
Ensuring that users use a lengthy password containing a random mix of
characters should prevent other users from guessing each other's passwords
and gaining access to resources they shouldn't have access to. Physically
securing access to the password databases should prevent unauthorized users
from using a brute-force cracking utility to obtain the passwords in use on
your FreeBSD system.
What we haven't looked at yet is restricting how users actually connect to
your FreeBSD system in order to receive a login prompt and attempt to use a
username and password. Let's make that the focus of next week's article.
Dru Lavigne is an
instructor at Marketbridge Technologies in Ottawa and the maintainer of the
Open Protocol Resource.
In case of broken links
please try to use Google search. If you find the page please notify
us about new location
Linux-PAM modules etc. page
Been Cracked Just Put PAM On It!
Strong
Passwords with pam_cracklib
Linux.DaveCentral.com System Utilities - Security, Page 1
Maximum
Security -- Ch 10 -- Password Crackers
Npasswd
Documentation
Alec Muffett's Home Page
Huge collection of word lists for
password checking, etc.
Cracklib
Proactive password security library by Alec Muffett. The idea is simple: try
to prevent users from choosing passwords that could be guessed by "Crack" by
filtering them out, at source.
Primary archive:
ftp://ftp.uu.net/usenet/comp.sources.misc/
John the Ripper Password Cracker
F Bergadano, B Crispo, G Ruffo,
Proactive Password Checking with Decision Trees, CCS 97 pp 67-77
The authors present a new
proactive password checking technique based on decision trees; the idea is to
help users avoid choosing weak passwords, but without the overhead of an
enormous dictionary. Using decision trees as password classifiers, they
managed to represent dictionaries with a compression factor of 100 and an
error of 1%. An accurate comparative evaluation with existing proactive
password checkers is also presented. The authors have released a public
domain implementation of their checker.
Maximum Security -- Ch
10 -- Password Crackers
passwd2.txt ``Foiling the Cracker'': A Survey of, and Improvements to,
Password Security- Daniel V. Klein Software Engineering Institute Carnegie
Mellon University Pittsburgh, PA 15217 dvk@sei.cmu.edu +1 412 268 7791
With the rapid burgeoning of
national and international networks, the question of system security has
become one of growing importance. High speed inter-machine communication and
even higher speed computational processors have made the threats of system
``crackers,'' data theft, data corruption very real. This paper outlines some
of the problems of current password security by demonstrating the ease by
which individual accounts may be broken. Various techniques used by crackers
are outlined, and finally one solution to this point of system vulnerability,
a proactive password checker, is proposed.
GeodSoft
How-To Cracking Passwords Techniques
|
Both Crack 5
and John the Ripper allow the user to define rule sets that
control the transformations that are applied to the input
dictionaries (word lists). Below are most of the
transformations that John the Ripper can perform. Crack has
the same capabilities.
- Append or prepend
defined characters to a word.
- Reverse a word.
- Duplicate a word.
- Mirror a word, i.e.
append the reversed word.
- Rotate a word either
left or right, i.e. move the first letter to the end or
the last letter to the front.
- Upper case a word.
- Lower case a word.
- Make only the first
letter a capital.
- Male all but the first
letter a capital.
- Toggle the case of all
characters.
- Toggle the case of a
character at a set position.
- Minumum and maximum word
lengths can be set or long words can be truncated at a
set length.
- Suffixes (s, ed, ing)
may be added to words.
- First, last or any
specific character may be deleted.
- Characters can be
replaced at a set location.
- Characters can be
inserted at a set location.
- "Shift" the case, i.e.
substitute the other character on the same key, e.g. 'a'
and 'A' or '5' and '%'.
- Shift the characters
left or right by keyboard position (so an 's' becomes an
'a' or 'd').
- Replace all of one
character with another.
- Replace all characters
of a class (for example vowels, letters, non letters,
digits) with a specific character.
- Remove all occurrences
of any character from a word.
- Remove all characters of
a class from a word.
- Reject a word if it
contains or doesn't contain a character, or characters
from a class.
- Reject a word if the
first, last or set character is or is not a specific
character or from a class.
- Reject a word unless it
contains at least so many of a character or characters
from a class.
In the
forgoing a class might be any of the following: a letter, a
vowel, a consonant, an upper case letter, a lower case
letter, a digit, a symbol or punctuation, a non letter
(digits, symbols and punctuation), alphanumeric or one of
several others. The length limits and reject options don't
increase the possibilities but allow the cracker to skip
"words" where a particular type of transformation may not
make much sense; this should improve the cracking tool
efficiency. |
|
Etc
Copyright © 1996-2008 by Dr. Nikolai Bezroukov.
www.softpanorama.org was
created as a service to the UN Sustainable Development Networking Programme (SDNP)
in the author free time.
Submit
comments This document is an industrial compilation designed and created
exclusively for educational use and is placed under the copyright of the
Open Content License(OPL).
Original materials copyright belong to respective owners. Quotes are made
for educational purposes only in compliance with the fair use doctrine.
Standard disclaimer: The statements, views and opinions presented on
this web page are those of the author and are not endorsed by, nor do they necessarily
reflect, the opinions of the author present and former employers, SDNP or any other
organization the author may be associated with. We do not warrant the correctness
of the information provided or its fitness for any purpose.
Last modified:
June 05, 2008