Fun Password Facts

by hairball  (hairball@illgotten.net)

In the course of a computer security professional's everyday web surfing, we can't help but come across several programs that can do interesting things with passwords.

From the everyday UNIX/Linux password cracker to the Windows brute-forcing programs strewn all over the Internet, I see the same single problem that seems to envelop most of them.

Many read from a password list instead of generating the passwords as they go.  While this makes perfect sense when used with "most common passwords" lists and all, when it comes to brute-force this is very impractical due to the large number of possible password combinations.

Let's do a little investigation.

As many of you probably already know, the ASCII character set contains a total of 256 unique characters.

Remember that a byte is eight bits, and that a bit is a one or a zero.  Therefore, in the range 00000000 - 11111111, only 256 possibilities exist.

So every file in existence can only contain combinations of these 256 characters and nothing more.

Numbered 0-255, each character possible has its own ASCII code.  The first 32 codes (0-31), when it comes to textfiles, are control codes.  These codes, which date back to MS-DOS 1.0, are passed from program to program to perform certain functions.

For example, code 7 is the "BEL tone" code.

This is the code that causes your computer to send the motherboard the command to make your onboard PC speaker beep.  On a PC compatible system, entering a raw ASCII command is as simple as holding down the Alt key and entering its code on the numerical keypad (not the one above the letters).

Here's a simple example:

1. Open a DOS window (C:\COMMAND.COM on most versions of Windows/DOS).
2. At the command prompt, enter ECHO, and a space.
3. Now, hold down the Alt key, and press 7 on the numerical keypad.
4. Release the Alt key.
5. Your screen should say something similar to: ECHO ^G
6. Now, press the Enter key.

Since the DOS command ECHO tells your computer to spit back at you what you just entered, it will display the control character on your screen.

But the code you just entered is not a visible character; it is the bell tone code.  Instead of ^G being proudly displayed, one of two things will happen.

Depending on your system configuration, either your PC speaker will beep (sometimes it will just click on cheap motherboards), or Windows will play the "default beep" sound file that's programmed in the system settings.

In the latter case, Windows simply intercepts the motherboard's beep command and interprets it internally.

Other control characters include "backspace" (8), "linefeed" (10), and "carriage return" (13).

Each of the ASCII control characters also has a simple keyboard command, such as "break" (3) which is Ctrl+C.  Notice how the above bell tone example displayed ^G on the screen?

This is because Alt+7 and Ctrl+G are the same ASCII command character.  This is how functions such as Ctrl+C (copy) and Ctrl+V (paste) work in Windows.

Here's a simple example:

1. Open a DOS window (again).
2. At the command prompt, enter DIR, the DOS command to list the files in the current directory.
3. Now, hold down the Alt key, and press 1, 3 on the numerical keypad.
4. Release the Alt key.
5. Notice that the directory was displayed.  This is because Alt+13 is the same as Enter.
6. Now, try it again by entering DIR at the prompt again.
7. This time, instead of Alt+13, use Ctrl+M.
8. Notice the same thing happens, because Ctrl+M is the same as Alt+13.

ASCII codes 32-126 are where the common keys are: A-Z, a-z, 0-9, plus all the symbols keys, space, and whatnot.  99.9 percent of the time a system password will consist of nothing but these characters.

ASCII codes 127-255 are the "extended" characters.  These codes are characters with accent marks, drawing characters, and other such novelties.  These characters are interpreted differently in DOS and Windows environments, and cause a lot of compatibility issues.

For this reason, they are mostly not well understood by the Windows generation.  At a DOS window, try Alt + 176, 177, 178, 219.  These are shading effects used in old-school DOS programs.

Also, check out the border drawing set, Alt+(179-222).  If you have ever seen a DOS program that draws a border around itself without any graphical modes, this is how it does it.

UNIX and Linux, because of the nature of the OS itself, can handle passwords made up of almost any combination of almost any of the 256 characters.  Unfortunately, password files simply cannot contain all of this.

The only characters that I know of that can't be used in a UNIX/Linux password is code 0 and 13.  Remember from the above example that 13 is the same as Enter.

So how would a password be able to contain an Enter as a character?  It can't.

Code 0 is Null, and entering nothing is nothing.  Linux passwords can, however, contain the linefeed character.

This is where Windows has some trouble.  In Windows, both a linefeed and carriage return are needed to end a line in a text file.  But in UNIX/Linux, they both perform a different function.

A linefeed is a control character that says, "Go to the next line."  A carriage return is a control character that says, "Go to the beginning of the line."  So in a normal Windows/DOS text file, each line ends with both a linefeed and a carriage return.

Here's an example:

What your computer sees:

Joe is COOL.[CR][LF]He likes Cheese Pizza![CR][LF]DMCA Sucks.

What you see:

Joe is COOL.
He likes Cheese Pizza!
DMCA Sucks.

Your computer displays the first part, "Joe is COOL."  It hits the carriage return code and puts the cursor back at the beginning of the line - at the J in Joe.  Then it hits the linefeed character and takes the cursor down one spot, right below the J in Joe, which is the beginning of the next line.

It continues displaying the next line, "He likes Cheese Pizza!" until it hits the CR and LF again and repeats the process.  This is how each sentence appears to be on its own line, even though a text file is a continuous string of data.

The problem arises when one of the characters is missing.  Let's say for some reason the text file does not contain the carriage return control characters.

What your computer sees:

Joe is COOL.[LF]He likes Cheese Pizza![LF]DMCA Sucks.

What you see:

Joe is COOL.
            He likes Cheese Pizza!
                                  DMCA Sucks.

This is because the computer displays the first part, "Joe is COOL.", hits the linefeed control character, and spaces the character down one line where it left off.  Since there is no carriage return, the computer does not reset the cursor at the beginning of the line and it just starts printing where it left off, just one line down.

Now let's say the same text files now have carriage return, but are missing the linefeeds.

What the computer sees:

Joe is COOL.[CR]He likes Cheese Pizza![CR]DMCA Sucks.

What you see:

DMCA Sucks.eese Pizza!

This is because the computer prints the first part, "Joe is COOL.", then hits the carriage return control character and sets the cursor back to the J in Joe.  Then it continues with the next line, "He likes Cheese Pizza!," overwriting what was on the screen before.  Since there was no linefeed, the computer did not go to the next line.

The most common place you may experience problems from CR and LF mismatches is during Telnet and terminal sessions.  Telnet is not as much of a problem because most servers have adopted the VT100 standard, but using a terminal emulator on a modem has been famous for this kind of trouble.  Also CR and LF play a major role when using a dot-matrix printer.  Anyhow, back to the file formatting.

This is why sometimes if you copy a text file from one operating system to another, it doesn't open right.  There are simple ways to fix this, such as opening them in a program that understands the format, then resaving them.  But the fact is that UNIX/Linux and Windows/DOS use different text file formats, and the size of a password file will be larger on a Windows/DOS system than a UNIX/Linux system.

Windows/DOS requires a text file to have both the linefeed and carriage return codes, while UNIX/Linux requires only the carriage return (under most configurations).

So, let's get to the math.  As discussed earlier, a password can contain any of the characters except the Null (code 0) and the carriage return (code 13).  So the question is, how big would a text file be that contains every possible UNIX/Linux password?

Let's figure it out.

For all practical purposes, we are going to assume the password can be made of any ASCII character except 0 and 13, and that it can be between zero and eight characters long.

So, of the 256 possible characters, we are going to be using 254 of them.  Let's make a chart of the possibilities.

We know that there's only one zero-character password, a blank one.

Now, for each of the remaining combinations, we are going to use the formula: 254^{(Number of characters)}

This will give the possible combinations of 254 characters for any given length of password.

Number of 0 Character Passwords: 1 Number of 1 Character Passwords: 254 Number of 2 Character Passwords: 64,516 Number of 3 Character Passwords: 16,387,064 Number of 4 Character Passwords: 4,162,314,256 Number of 5 Character Passwords: 1,057,227,821,024 Number of 6 Character Passwords: 268,535,866,540,096 Number of 7 Character Passwords: 68,208,110,101,184,384 Number of 8 Character Passwords: 17,324,859,965,700,833,536 Total: 17,393,337,673,075,145,131

Whew!  That's a lotta passwords!  But how much hard disk space will a plaintext list of them all take up?

Well, let's do more math!

Let's assume the password list will be stored on a Windows/DOS system.  This means that every entry will require a carriage return and linefeed byte to maintain the text file format.

So, here's the formula:

Size = [Number of X digit passwords * (X + 2)]

Breakdown:  The space needed on the hard drive to store this set of passwords (in bytes) is equal to the number of password combinations in the set, times the length of each password plus 2 (carriage return and linefeed).

Example:  There are 254 one-character combinations.  So that's 254 passwords times a length of three.  Each password is three characters long because of the one-character size, plus the carriage return and linefeed.

Okay, lets form another table:

X: # of Passwords * (Digits + 2 ) = Size in Bytes ----------------------------------------------------------------------- 0: 1 * (0 + 2) = 2 1: 254 * (1 + 2) = 762 2: 64,516 * (2 + 2) = 258,064 3: 16,387,064 * (3 + 2) = 81,935,320 4: 4,162,314,256 * (4 + 2) = 24,973,885,536 5: 1,057,227,821,024 * (5 + 2) = 7,400,594,747,168 6: 268,535,866,540,096 * (6 + 2) = 2,148,286,932,320,768 7: 68,208,110,101,184,384 * (7 + 2) = 613,872,990,910,659,456 8: 17,324,859,965,700,833,536 * (8 + 2) = 173,248,599,657,008,335,360 Total: 173,864,628,360,502,142,436

So, how big would a Windows/DOS text file that contained every possible UNIX/Linux password be?

Looks like 173,864,628,360,502,142,436 bytes.  That's 169,789,676.2 terabytes.

Well, this is every possible password ever, but remember I said that 99.9 percent of all passwords only used characters between ASCII codes 32-126?

Let's figure this whole thing out again using this set instead of the whole shebang:

Number of 0 Character Passwords: 1 Number of 1 Character Passwords: 95 Number of 2 Character Passwords: 9,025 Number of 3 Character Passwords: 857,375 Number of 4 Character Passwords: 81,450,625 Number of 5 Character Passwords: 7,737,809,375 Number of 6 Character Passwords: 735,091,890,625 Number of 7 Character Passwords: 69,833,729,609,375 Number of 8 Character Passwords: 6,634,204,312,890,625 X: # of Passwords * (Digits + 2 ) = Size in Bytes ----------------------------------------------------------------------- 0: 1 * (0 + 2) = 2 1: 95 * (1 + 2) = 285 2: 9,025 * (2 + 2) = 36,100 3: 857,375 * (3 + 2) = 4,286,875 4: 81,450,625 * (4 + 2) = 488,703,750 5: 7,737,809,375 * (5 + 2) = 54,164,665,625 6: 735,091,890,625 * (6 + 2) = 5,880,735,125,000 7: 69,833,729,609,375 * (7 + 2) = 628,503,566,484,375 8: 6,634,204,312,890,625 * (8 + 2) = 66,342,043,128,906,250 Total: 66,976,482,088,208,262

So, a plaintext Windows/DOS format text file containing every possible Unix/Linux password for ASCII characters 32-126 would be 66,976,482,088,208,262 bytes which is 65,406.7 terabytes.

Quite a large file.

Perhaps now you can understand why I am forced to laugh when I see a program on a web page or BBS that claims to be able to generate a complete password list using the entire ASCII alphabet.  Sure, the program probably could do it, if it had two million terabytes to work with.  And, oh, it would probably take a few decades too.

My point being, brute-force is a real time-consuming game.  It takes raw power that most of us just don't have available.  If you need to brute-force, then you'll need to get a program that generates the password list as it goes, therefore making the requirement for free hard drive space a little less.

While most of you probably knew that a complete password list would be quite a large file, even I was guilty of thinking a 40 GB hard drive would handle the job.

By writing this article I hope to have opened a few people's eyes and save you the wasted time of trying to accomplish something that is, at best, a bad idea.

In conclusion, I have a question.  What do you and all the computers you come in contact with all have in common?  They both are capable of doing whatever the hell you want.  Peace out.

Greetz: sybah, tekniq, radiate, MrT, myke@LM
[Special Thanks to Windows Calculator]