Author: JT Smith
In this article we will discuss practical issues related to password policies, learn some basics about passwords, and teach our ‘Linux baby’ (ourselves) some good manners about password security.Lets start with some basics….
“/etc/passwd” file: the password database
Our Linux system stores its usernames and passwords in a special file : ‘/etc/password’. The passwords in this file are one way encrypted (hash-ed) through a password encryption function called ‘crypt’ using DES as the encryption algorithm. The good thing about ‘hashing’ is that you can not ‘decrypt’ the hashed passwords because the function used for hashing cannot be reversed (one-way traffic). DES generally uses keys (symmetric key cryptography) in which case things can be either encrypted or decrypted, but for encrypting passwords in Linux, only the ‘hashing’ implementation of DES is used.
Now , from that, let’s move on to some more details about the ‘/etc/passwd’ file. Our file has user entries in the following format :
user:encrypted-password:UID:GID:GECOS:home-directory:user-login-shell
Or more specifically :
username:Npge08pfz4wuk:503:100:Full Name:/home/username:/bin/sh
Lets pause for a moment and analyse the second (the encrypted/encoded password ) field closely. Here, Np is the ‘salt’ and ge08pfz4wuk is the ‘encoded password’. The ‘salt’ is a two-character string chosen from the set [a-z A-Z 0-9./] so that a single password can be encoded in 4096 ways. The encoded salt/password could just as easily have been kbeMVnZM0oL7I and the two are exactly the same password, which is “password”.
Now the other fileds… UID and GID are the numeric IDs of the user and the corresponding group to which he belongs , respectively. For ‘root’ both UID and GID = 0.
The GCOS (General Electric Comprehensive Operating System) field contains user information like name, phone number, and organization. It can be left empty.
The home directory field refers to the path of user’s home directory, which is generally ‘/home/
home directory for ‘root’ is ‘/root’.
Login process
When you login to a Linux system the login process encrypts the password provided by you (DES encryption), and compares it with the encrypted password in the ‘etc/passwd’ file. Since the two passwords have been encrypted using the same one-way hashing algorithm, if they are same the user is granted access. Otherwise the user is denied access.
Here we face one problem: The passwd file has to be read by ‘everyone’ so that processes like ‘login’ are able to access it for authenticating the user. Therefore this passwd file can be accessed by any user and run through a dictionary based password cracker like ‘cracker’ or ‘john the ripper’ to get passwords in clear text.
If you are wondering what a dictionary based password cracker is, let me explain. A dictionary based password cracking program takes words or combination of alphanumerics/numerics specified in a dictionary file and encrypts them using the same DES algorithm which /etc/passwd uses, to guess the real password. This process continues till the password cracker is out of dictionary words or the real password is found.
To solve this problem , the concept of shadow passwords was conceived.
Understanding shadow password suite
If you are using a shadow password suite, your encrypted passwords are stored in the ‘/etc/shadow’ file and the ‘etc/passwd’ file will have ‘*’ in place of encrypted user passwords.
After the shadow suite is installed, the ‘/etc/passwd’ file will look something like this:
username:x:503:100:Full Name:/home/username:/bin/sh
The shadow suite removes the paswwords from ‘/etc/passwd’ and puts them in ‘/etc/shadow’. Only root will be able to read and write to the /etc/shadow file.
This means that any program that reads the ‘/etc/passwd’ for purposes other than authentication will still operate correctly.
For instance, a program like ‘/bin/ls’ uses ‘/etc/passwd’ to map the user ID to the proper username in a directory listing. This dependency can be proved by a simple example: Suppose you remove all permissions from the /etc/passwd file so that, to any user other than root, this file is inaccessible and one of these users (other than root) does a ‘ls -l’. What he will get is a directory listing and his UID but never his username string.
Some programs (like xlock) don’t need to be able to change passwords, they only need to be able to verify passwords (authentication). These programs can either be run SUID root (from the security point of view , this is not acceptable) or relatively better, you can set up a group shadow that is allowed read only access to the /etc/shadow file. Then the program can be run SGID shadow.
Setting password aging
An entry in the file :/etc/shadow has the following format:
user name :encrypted password : last modified :min change : max change days : warn days : disable days : disable time : reserved
here,
username = The User Name
passwd = The Encoded password
last modified = Days since Jan 1, 1970 that password was last changed
Min change(days) = Number of days before the user can change his/her
password
Max change(days) = Number of days after which the user has to change his/her
password
warn = Days before password is to expire that user is warned
expire = Days after password expires that account is disabled
disable = Number of days after the account has expired that it should be locked.
disable time = Days since Jan 1, 1970 that account is disabled
reserved = A reserved field
Password aging can only be enforced by the ‘root’ for any user.
The command used is :chage
c
Suppose we have a user ‘shash’ for whom the password aging has to be set. We use the command ‘chage’ (not change!) to specify all fields related to password policies in the ‘/etc/shadow’. When we run ‘chage
(The arguments specified within ‘[ ]'(square brackets) are defaults and will be
implemented in case you press
[root@lord] chage shash
Changing the aging information for shash –
Enter the new value, or press return for the default
1) Minimum Password Age [0]:
this refers to the ‘min change’ field.The default value=0 for this field implies that the user can change his/her password anytime.
2) Maximum Password Age [30]:
Corresponds to ‘Max change’ field.default=30 days default is a pretty decent choice.
3) Last Password Change (YYYY-MM-DD) [2001-09-20]:
Corresponds to ‘last modified’ field.better leave it at default.
4) assword Expiration Warning [7]:
Corresponds to ‘warn ‘ filed
5) Password Inactive [-1]:
Corresponds to ‘expire’ field.The default value of ‘-1’ means -password never expires-.
6) Account Expiration Date (YYYY-MM-DD) [1969-12-31]:
Corresponds to ‘disable’ field.the default value(a ‘date’ going down in past)
Now, if you want to see the password aging information of a user, do this :
[root@lord] chage -l
You would see all the aging information for this user.
Also, just for the sake of awareness, there are other files that come in this
whole ‘Linux passwords’ scene:
/etc/login.defs = login definitions
/etc/gshadow = shadow user group file
/etc/groups = user group file
Password auditing on Linux using John The Ripper
Ok. Now it’s time to turn the tables on those crackers by using their favorite tool. There are lots of password crackers for *nix systems available in the wild. We are going to learn to use one of them to check the strength of our passwords.
The object under consideration is a password cracker called ‘John the Ripper’.
(nice name, and does a good job of it also 🙂 )
Installation
step 1: download source package from here :www.openwall.com/john
step 2: (unpacking the archive)
[root@lord] tar -zxvf john-1.5.tar.gz
step 3: [root@lord] cd john1.5
[root@lord] cd src
[root@lord] make linux-x86-any-elf
Just typing ‘make’ and pressing
Since there is NO ‘make install’ step here, we will just copy the john executable(which is in
[root@lord] cp
Configuring
The configuration file for john is ‘john.ini’.
The only option which you really would like to configure is the name and path to the dictionary file that john is supposed to use. look for this line:
***snip*****john.ini*****
#Wordlist file name, to be used in batch mode
Wordfile = ~/password.lst
*********snip*********
Here you can give the name and path of the dictionary file you want john to use.
The default is a file ‘password.lst’ in the current directory. A dictionary file is supposed to have a big collection of common words and numeric and alphanumeric combinations. The bigger your dictionary file, the more chances john has for cracking passwords.
Note: Whenever I refer to ‘~/’ (current directory) here, it means we are referring to some file in the directory:
Kindly note that the first 3 options specified here (a,b,c) are used for cracking passwords for systems which DO NOT have shadow suite installed. So effectively all encrypted passwords are assumed to be in ‘/etc/passwd’ and there is NO ‘/etc/shadow’.
a)to make john make enough random tries to crack passwords :
[root@lord] john /etc/passwd
b)to make john launch a dictionary(here the wordfile/dictionary is in current
directory) attack for password cracking :
[root@lord]john -wordfile:
c) john stores the cracked passwords in the file: ~/john.pot.
to read the cracked passwords, do:
[root@lord]john -show /etc/passwd
Now if you are using the shadow suite (wise choice!), ‘/etc/passwd’ and ‘/etc/shadow’ have to be merged for for john to be able to crack passwords. For this we have to invoke the john executable as ‘unshadow’.
Lets start by creating a symbolic link for john as ‘unshadow’ :
[root@lord] ln -s /usr/local/bin/john /usr/local/bin/unshadow
and then invoke ‘unshadow’ :
[root@lord] unshadow /etc/passwd /etc/shadow > mergedpass
we now have the required ‘merged’ file called ‘mergedpass’ (you can give it any
name you want) and we are ready to crack it as :
[root@lord] john mergedpass
or
[root@lord] john -wordfile:
Eof.
Now before you reach out for that asprin, lets consider those ‘good manners’ I was referring to in the beginning of this document:
The following are the Do’s and DONT’s for a good password policy :
DON’T use these things for your password
- The username name .
- Any word found in a dictionary
- Names of people or things
- Keyboard sequences like “asdf”
- Any publicly available information about you e.g. your phone number or
credit card number
MUST DO’s:
- Keep longer passwords(but Password should be a mixture of numbers and letters
- Password should be a mixture of uppercase and lowercase letters
- Do regular checks of the password strength of all your networked systems irrespective of the OS — they are running. You can use john-the-ripper for Linux systems and L0pht-crack (www.l0pht.com) for WindowsNT/2000 systems.
Practically speaking, you should not keep password length more than 8 characters since the
first 8 characters have more importance than the rest (if you’r using password length =>8), and somebody will only need to break the first chunk of 8 bytes to get around the other ones very easily. And anyway, it’s not very neurologically viable to remember passwords > 8 characters, especially when it doesn’t do any good!
Please note that in most of the cases we have a hybrid network, i.e. a network comprising machines running different OSes, like some machines running Linux and others running WinNT etc. In theses cases it becomes absolutely essential to enforce similar security policies (and right now, the password policies) on all machines, because even if one system on your network gets penetrated, it can be effectively used to gain privileges over the whole network. If you have a NASA-like security policy for your Linux machines, and your connected Windows machines are as vulnerable as a ‘newly born bird’, you are a gonner!
Conclusion
- Implementing security is a chain of sequential events.
- Each event is a link of this chain.
- The strength of ‘each’ link shall make or break this chain. It’s no use spending your time, energy and money on all those firewalls and IDSs if anybody can login to your account using your wife’s first name as your password!
To be very frank, no software, no hardware can protect your digital assets if you are not concerned enough. Its you who has to enforce security, be alert, and be paranoid about security.
-------------------------------------
Author : Shashank Pandey a.k.a ~AcE~
E-mail : reach_shash@linuxmail.org
-------------------------------------
About the Author
The author is an undergraduate student of Computer science and works as ‘I.T. Manager’ at a New Delhi (India) based Total I.T solutions organization. He is also actively involved as a freelance Information Security consultant, and swears by ‘information dissemination’.
(c)CopyLeftRightandCenter 2001. Shashank Pandey
All Rights reserved. Unauthorized copying or duplication of this document is prohibited.
Category:
- Linux
