|
|
Home | Switchboard | Unix Administration | Red Hat | TCP/IP Networks | Neoliberalism | Toxic Managers |
| (slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix | |||||||
| News | See Also | Papers | Reference | Stanford 2004 Compromise | |
| npasswd | PAM-based checkers | Crack | John the Ripper | Humor | Etc |
| First and foremost, not too much zeal Talleyrand advice to young diplomats |
|
|
The power and usefulness of password crackers are greatly overhyped. First of all if password is checked for strength by OS (and in the most simple case that means, length >6, no dictionary word, combination of letters and numbers, combination of upper and lower case and at least one punctuation mark) without some additional information to crack it next to impossible unless you are working for three letter agency and have access to special equipment.
|
|
I used to use a pretty simple 6 symbol password on most systems. Still cracking it without some knowledge of the composition requires years of work: 6^44 is a pretty big number, bigger than classic 2^64 of chess fable fame).
Of course now I use at least eight symbol passwords but not so much to be more secure as because systems are pretty paranoid and complain if password is less then eight character long. Which is OK with me.
In real life unless you manage to steal the shadow file from some server, it's impossible to apply cracker to the system: one way or the other stream of attempts to guess password will be detected; most correctly configured systems also block account after five or so attempts for an hour or so. 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 is already penetrated. The only realistic assumption here is that users typically reuse passwords on other servers. But it is much easier and much more productive to fight this battle and requre users to use unique password on each server/web site, then to increase the complexity of passwords beyond reasonable limit.
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 seven unsuccessful attempts, then even a weak password can withstand most of the attacks. But still due diligence is not a bad strategy.
It's important to understand that shadow files that contain password hashes are readable only by the root user. In a way, the introduction of shadow file devalued the importance of crackers. Still if hashes can be intercepted (for example if NIS is used) crackers can be used against them.
|
Excessive zeal in enforcing strength of passwords actually can compromise security. |
All in all password security has a lot of urban legends that have no connections to reality. Excessive zeal in enforcing strength of passwords actually can compromise security. As we tried to show weak passwords in not a crime, but reuse of the same password on different servers, especially for servers that contains critical (financial) data is.
There are two major cracker implementations:
Crack by Alec Muffett Unix, free (Perl Artistic License). Here is how it is characterized at Unix Password Crackers page of Openwall 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.
|
One definitely useful application of crackers is their usage |
|
|
Switchboard | ||||
| Latest | |||||
| Past week | |||||
| Past month | |||||
 |
 |
 |
|
|
|
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_authtokThe 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_authtokWARNING
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.
|
|
|
|
|
|
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 chap Pluggable Authentication Modules (PAM) in the Red Hat Linux Reference Guide.
|
|
|
In last week's article, we looked at which parts of a password policy could be implemented by editing the
/etc/login.conffile 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 ttyv4To 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
cryptthat uses either the "DES" or the "MD5" encryption algorithms to encrypt passwords. If you're curious to see the technical details on howcryptworks, readman 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 utilitycrypt(1)with the functioncrypt(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 cleanOnce 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
cdinto or view the contents of this directory.To run the password cracker, type:
./Crack -fmt bsd /etc/master.passwdand 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
DoneOn 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 tidyfrom the
/usr/local/crackdirectory. It is also a good idea to manually delete therun/F-mergedfile, 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:dlavigneNotice that it shows the encrypted hash followed by the cracked password, which is pretty sensitive information to leave on hard disk.
rm run/F-mergedOne 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 cleanOnce it's finished building:
cd /usr/local/share/john unshadow /etc/passwd /etc/master.passwd > passwd.1 john passwd.1At this point, you'll lose your prompt for a long period of time; if you use the
topcommand 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 -d1last 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 zombieMem: 61M Active, 11M Inact, 22M Wired, 4380K Cache, 22M Buf, 23M Free
Swap: 260M Total, 260M FreePID 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% cshWe'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
unshadowboth password databases into a file before we could run thejohnutility. 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.
Google matched content |
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
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 [email protected] +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.
Society
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
Quotes
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Bulletin:
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
History:
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
Classic books:
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D
Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|
|
You can use PayPal to to buy a cup of coffee for authors of this site |
Disclaimer:
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.
Last modified: April 27, 2021
