By: James Reynolds - Revised: 2006-05-23 devin


There are 2 types of password vulnerabilities. One is a plain brute force login attempt. That is when a user (or more likely script) tries to login with common usernames and passwords until a match is found. This is a common network attack against ssh.

The other is type of vulnerability is when the "encrypted" password file is obtained. It is getting continually easier and easier to crack the encrypted password files, almost to the point that they are useless. So keeping them safe is getting to be the only way to protect yourself from this, unless you have the resources to use 2-factor authentication, like a password PLUS fingerprint/retina scan.

Encrypted Password File Problem

NOTE: The following vulnerability only applies to Mac OS X 10.2.x "Jaguar" and previous versions. Mac OS X 10.3.x "Panther" uses shadowed passwords. In Panther, the vulnerability ("nidump passwd .") just prints out asterisks for the password information.

When Unix first came out, passwords were stored in a file (/etc/passwd). Unix login requires that everyone be able to read the file. The problem with this is that it allows others to read other users' password in the file. The solution was to stores passwords as a cryptographic hash.

A cryptographic hash is a one-way encryption. Two-way encryption is what most people think of when they hear "encrypted". Something encrypted can be decrypted with a password, passphrase, or key. On the other hand, a one-way hash can not be returned to the original with any password, passphrase, or key.

The computer never knows the original password, only the hash of the password. This works for login because the system never needs to know the password. It only needs to prove the user logging in knows it. It does this by asking for a password, hashing it, then comparing the hash with the hash in /etc/passwd. If they match, the user typed the correct password.

The problem is, anyone can hash a password. If you hash a dictionary, you can compare it with the contents of /etc/passwd and find out if a user is using a dictionary password. For example, it took about 2 seconds for a G4/450 dual processor to find the hash for "Sandra" and "Jackie", two passwords I tested.

In addition to that, you can just hash every possible 8 character password combination. For years, computers were too slow to hash every possible 8 character password combination. However, computers got fast.

In fact, as of late 2005, there are now "commercial" cracking databases, for example, using a 500 gigabyte database of pre-cracked passwords.

Most Unix operating systems today use what is called a shadow password file. It contains the actual hashed passwords and is not readable by anyone. The world-readable file (/etc/passwd) contains nothing useful. Mac OS X 10.2.x and below does not support shadow passwords (Mac OS X 10.3.x supports shadowed passwords). Anyone can read the passwords. However, they are not stored in /etc/passwd, but in the NetInfo database.

Encrypted Password File Solution

Even when using systems with shadow passwords, there are still methods of getting the hashed password (but they are difficult for normal humans). Because stealing password hashes is still possible, top security exports do not view it as really "secure". The only real secure solution is to store passwords on a remote computer that general users can not access.

Apple supports remote password storage using Kerberos, Password Server, or other directory services to combat local exploits. For more information on this, read the "Integration and Infrastructure" documentation.

The rest of this document discusses how to create good passwords, safe password practices, more about cracking a password, and some things you can do if you have to use local passwords.

Strong Passwords

The best protection against cracking is to use strong passwords. Here are some good rules to follow when creating passwords:
  1. Use at least 8 characters, preferrably more (but Mac OS X doesn't support this yet).
  2. Use all 4 types of characters: upper case, lower case, numbers, and special/punctuation characters.
  3. Never use a real word, abbreviation, text pattern, number sequence, name, or jargon term (or word/etc that might appear in another language). Examples include "diatonic", "ASCII", "qwerty", "555-1212", "Reynolds", "lpstat", "Verstehe"
  4. Never use any word in the above category spelled backwards, with number sequences following or preceding, with only common numbers/symbols replacing letters. Examples include "sdlonyeR", "bla12345", "111qwerty", "R3yn0!d5". I really smart password cracker can crack these.
  5. Example of a good password: Ju&dM*@D = Jump Up And Down Many Times A Day (with a little practice, most people should be able to type this quickly). The difference between Ju&dM*@D and R3yn0!d5 is that R3yn0!d5 is still a dictionary word only with modified characters.
  6. Or use a Password generator.

Safe Password Practice

In addition to good passwords, it is important to use safe password practice. These rules are not so much to protect you from crackers in general, but to protect you from smart crackers. They go for the weakest link, and there are many links weaker than the password hash. Here are some good rules to follow:
  1. Email is no place for a password.
  2. Chat is no place for a password (iChat included).
  3. Only save strongly encrypted passwords (PGP, GPG, etc).
  4. Never write a password down (or if you must for some reason, don't save it but destroy it).
  5. Never say your password to someone on the phone.
  6. Never whisper your password as you type it.
  7. Never say your password on voice mail.
  8. Never say your password.
  9. Teach other users these rules.
  10. Pick a password you can type quickly or practice typing the password so you can't be observed in a lab (this is moot if you are in front of a camera--so never put any of your computer keyboards in front of a camera--and watch out for those tiny wireless cams).
  11. Be aware that some user may have installed a key recorder before you type your password. Only use trusted computers or change your password after you use an untrusted network.
  12. Do not use applications that can not encrypt passwords (telnet, ftp are bad, instead use ssh and sftp).
  13. Type passwords only into a webpages that begin with "https" in the location.
  14. Change passwords at least once every 6 months. This is not often enough. But considering the alternative is that you might change your password once every other year, 6 months is a good goal.
  15.  Use unique passwords for different servers/websites/organizations. Never use the same password on a lab computer that you use on a server. VERY BAD IDEA. Same goes for websites. Websites that require registration should not be trusted at all. If I threw up a webpage that asked for a username and password, how many people would put in their username and password that they use everywhere without thinking twice?

Dictionary Attack

The best cracker program would not only encrypt the dictionary, but every possible manifestation of a word. For example, "cracker" would be not only be encrypted as "cracker", but also as "Cracker", "CRacker", "CrAcker", "cr@cker", "cr@ck3r", "kracker", "crackur", "cracker123", "cracker111","cracker222", "rekcarc", etc.

Crack and John the Ripper

You should crack your own passwords to see how long it takes. You can use Crack or John the Ripper.

Get Crack here. Read the Crack faq here. Read instructions how to compile Crack on Mac OS X here.

Get John the Ripper here. To compile John the Ripper (1.6), just open the file john-1.6/scr/Makefile and comment out line 18:


OPT_NORMAL = -funroll-loops


# LDFLAGS = -s
OPT_NORMAL = -funroll-loops

Then in the terminal type (requires Dev. tools):

make generic

It will take awhile to compile and there will be many warnings but it will work. Read the documentation to use it. I found that John the Ripper was much faster than Crack getting the easy passwords. It took 2 seconds to crack "Jackie" and "Sandra". It took about a day and a half to crack "thePass".

Other Bandaids

If you must use a local password, try these things too:
  1. Remove the world read and execute permissions for the following NetInfo files:
    • NetInfo Manager
    • nicl, nidump, nifind, nigrep, niload, nireport, niutil
    • /var/db/netinfo/local.nidb
  2. (10.1 only) Enable shadow password. This seemed to work in 10.1 but wasn't tested in a deployed environment. It hasn't even been tested in 10.2. You may want to see this page.
    • sudo -s
    • (type password)
    • mkdir /etc/lookupd
    • echo "LookupOrder CacheAgent FFAgent NIAgent" > /etc/lookupd/users
    • nidump passwd .
    • (copy the output)
    • (If you use pico, do the next line, if you like vi, skip it, if you like another, replace pico with the path to your editor)
    • setenv EDITOR /usr/bin/pico
    • vipw
    • (delete contents of file--except comments)
    • (paste)
    • cntr-x
    • y [yes to save]
    • y [yes to re-edit the password file, whatever that means]
    • Open NetInfo Manager and delete all the users so that nidump, nigrep, niutil, and nireport do not give out the password. And delete the file /var/backups/local.nidump. It should be recreated with the nightly cron script (and is used as a backup, so it is useful to keep around).


This issue isn't limited to Mac OS X. There are many sites that discuss this. Here are some: