28.0 Unix Passwords

The password file for Unix is located in /etc and is a text file called passwd. By default and by design, this file is world readable by anyone on the system. On a Unix system using NIS/yp or password shadowing the password data may be located elsewhere. This "shadow" file is usually where the password hashes themselves are located.

An entry in the password file consists of seven colon-delimited fields:

nomad:HrLNrZ3VS3TF2:501:100:Simple Nomad:/home/nomad:/bin/bash

This is what the fields actually are:

nomad

Account or user name, what you type in at the login prompt

HrLNrZ3VS3TF2

One way encrypted password (plus any aging info)

501

User number

100

Group number

Simple Nomad

GECOS information

/home/nomad

Home directory

/bin/bash

Program to run on login, usually a shell

The password field contains, yes, a one-way encrypted password. This means
that it is practically impossible to decrypt the encrypted password. The
password field consists of 13 characters - the first two characters are the
"salt" and the remainder is the actual hash.

When you log in with your account name and password, the password is encrypted and the resulting hash is compared to the hash stored in the password file. If they are equal, the system accepts that you've typed in the correct password and grants you access.

To prevent crackers from simply encrypting an entire dictionary and looking up the hash, the salt was added to the algorithm to create a possible
4096 different conceivable hashes for a particular password. This lengthens
the cracking time because it becomes a little harder to store an encrypted
dictionary online as the encrypted dictionary now would have to take up
4096 times the disk space. This does not make password cracking harder, just
more time consuming.

Unix passwords allow mixed case, numbers, and symbols. Typically the maximum
password length on a standard Unix system is 8 characters, although some
systems (or system enhancements) allow up to 16 characters.

Brute-force password cracking is simply trying a password of A with the
given salt, folowing by B, C, and on and on until every possible character
combination is tried. It is very time consuming, but given enough time
brute force cracking WILL get the password.

There are a few brute-force crackers out there for Unix passwords. Any
brute-force cracker will do

Dictionary password cracking is the most popular method for cracking Unix
passwords. The cracking program will take a word list, and one at a time
try to crack one or all of the passwords listed in the password file. Some
password crackers will filter and/or mutate the words as they try them,
such as substitute numbers for certain letters, add prefixes or suffixes,
or switch case or order of letters.

The most popular cracking utility is probably Alex Muffet's program, Crack. Crack can be configured by an administrator to periodically run and automagically mail a nastygram to a user with a weak password, or run in manual mode. Crack can also be configured to run across multiple systems and to use user-defined rules for word manipulate/mutation to maximize dictionary effectiveness - very flexible. However it is probably too much program for the novice script kiddie.

Another popular favorite is John the Ripper, based off of the popular DOS-based Jack the Ripper. Jack had a number of easy-to-use features, and Solar Designer took Jack's interface and developed John. To make things even better, Solar added Crack-like rules, and made sure the code would run on DOS or Unix. Either one is recommended. If you're going to be cracking on a DOS-based machine, use John the Ripper, otherwise either one is fine for Unix (the jury is still out on which one is best for Unix, it really depends on which one you are
used to using).

28.5 How does an admin enforce better passwords
and password management?

There are several techniques that an admin might employ to force users to
use better passwords, and several different packages that could be loaded and
configured onto most Unix systems to better secure the passwords.

One of the first techniques is to enforce password aging. While this varies
from system to system, basically password aging states that you can "expire" a
password. That way you can force a user to have to change his password periodically.

The security advantage is that if the user changes their password every 30 days, that stolen password file is obsolete after a month (in theory, see the next question). This alone is not real security unless it is used in conjunction
with other password techniques.

Some systems allow a minimal password length to be specified, certain dictionary words to be disallowed, or even disallow perceived "crackable" passwords. This in combination with password aging can help ensure that a user's password is probably going to be aged and therefore changed before it can be cracked.

Another very popular technique is called password "shadowing". This alters the password file entry slightly:

nomad:!:501:100:Simple Nomad:/home/nomad:/bin/bash

Note the "!" token in place of the one way encrypted password. This means that the password is located in a different file, typically called the shadow file. You will also find a "*" token on some shadow password implementations. On many Unix systems, the password file is still located in /etc but called shadow, some systems even place the shadow in a different directory. Here is a chart that lists a few systems, the location of the shadow, and the token.

System

Shadow

Token

AIX

/etc/security/passwd

!

BSD

/etc/master.passwd

*

DG/UX

/etc/tcb/aa/user/

*

HP-UX

/.secure/etc/passwd

*

IRIX

/etc/shadow

x

Linux

/etc/shadow

*

SCO

/tcb/auth/files/[first letter of username]/[username]

*

SunOS 4.1+c2

/etc/security/passwd.adjunct

##username

SunOS 5.x

/etc/shadow [optional NIS+ private secure maps/tables]

##username

System V < 4.2

/etc/shadow

x

System V >= 4.2

/etc/security/* database

x

Depending on the system and implementation, an encrypted password may still
be allowed in the password field, and lack of anything in the field implies lack of a password for that account. Some systems (AIX comes to mind) allow you to configure exactly what is allowed and not allowed as far as how the password field is used.

It should be noted most modern systems come with password shadowing already
set up and configured.

This will output the reconstructed password file, which you can save for
easy cracking in most common password crackers. This will not work on a
system using SRP (see below).

28.7 So what can I learn with a password file from a
heavily secured system?

Okay, so you've gained access to a system and can see the password file, but it is shadowed and haven't busted root (yet), or you are simply viewing the
password file, say through a CGI exploit. Here is an example:

SRP, or Secure Remote Password, uses a zero knowledge authentication
scheme. That is, only the user knows their password, there is never enough
cryptographic material going back and forth on the network to reveal the
password or its hash. The same goes for the password file -- there is
simply not enough material in the file to construct a hash. This means
that even if you crack a system with a remote root exploit and are sitting
at a root shell, you cannot grab password hashes to crack.

SRP has other useful features as well. It allows for complete
replacement of FTP and telnet with SRP-enabled versions (clients and
daemons), long passwords (up to 127 characters), and full encrypted
sessions for both FTP and telnet.