Secure Passwords - An Overlooked Strategy for Securing a Linux Server

Adopting a strategy of only using secure passwords is all too often overlooked particularly in a production Linux server environment. When I think back to my days working for Internet Service Providers I can think of many occasions where end users would become quite vocal if they were unable to have the password of their choice because I felt that it was simply not secure and posed a security risk to the ISP. One instance that comes to mind was a gentleman with an username of bill who wanted to have his password changed to bill so he could remember it. This is incredibly insecure and very easily broken. When I refused to change the password to bill he wanted it to be changed to bill1. This is obviously no better, it would be broken on the second pass instead of the first. At this point he became very irate, particularly when I suggested that he choose a secure password or I would choose one for him. Dont let your users bully you because they are incapable of grasping what is required to keep their account safe, ultimately the responsibility is yours to keep your Linux server secure. Consider all of the users on the machine when you make the decision as to what is acceptable.

Why is it such a big deal to have a secure password on all user accounts? Examine your Linux servers logs and you will plainly see the answer. Most break-in attempts on your Linux server will be in the form of brute force secure shell attacks, automated tools that attempt to log into your server by guessing your users passwords, system passwords and of course the root password. Some of these tools are quite intelligently conceived, using email addresses harvested off the internet to provide usernames for mail servers as an example. Once a mailbox has been successfully broken the attacker can send spam using mechanisms such as smtp auth. There are ways around this of course but it serves as an excellent example.

Choosing a Secure Password So we agree that bill and bill1 are not secure passwords. But Im sure we would all agree that EkKs2i7U is a very secure password. A secure password is alphanumeric (numbers and letters) with a mixture of upper and lower case characters, contains no dictionary words and is at least eight characters long. A password like EkKs2i7U would take several weeks to crack and would only be achieved the long hard way, by the password cracking software starting at aaaaaaaa and progressing from there, a time consuming task to say the least. Passwords such as this can become quite repetitive to create so if you need to generate lots of passwords on a regular basis consider tools such as this Free Password Generator to help you choose your passwords.

Locating Current Passwords that are Insecure

If your users have the ability to change their own passwords or if you have just moved into a new position and have been delegated the task of maintaining a Linux server you may feel it is necessary to check the level of security of the machines current passwords. The best way to do this is to attempt to crack the passwords yourself using a password cracking utility such as John the Ripper.

John the Ripper is a command line utility that allows the Linux server administrator to test the strength of the passwords stored in a password file. A copy of the Linux servers password file is required but I strongly urge you not to directly crack the servers password file directly. To test the strength of your users passwords you must first install John the Ripper as described on our Install John the Ripper password cracking utility page.

Once you have installed John change to the run directory and copy your password file into it. If your Linux server uses shadow passwords the password file must be unshadowed first as demonstrated below. To perform these operations you must have root access to the Linux server.

cp /etc/passwd . cp /etc/shadow . ./unshadow passwd shadow > newpasswordfile

Once your password file has been unshadowed simply run john with your unshadowed password file as the target. As John cracks your passwords it will display the password with the users login next to it in brackets. Bills password was broken in 2 seconds (seriously), Toms in less than a minute.

./john newpasswordfile Loaded 5 password hashes with 5 different salts (FreeBSD MD5 [32/32]) bill1                (bill) beach                (tom)

You can run John the Ripper in the background for as long as you like (try CTRL+z then type bg and press enter) and periodically check on its progress using the --show option.

./john --show newpasswordfile bill:bill1:1001:100:,,,:/home/bill:/bin/bash tom:beach:1002:100:,,,:/home/tom:/bin/bash 2 password hashes cracked, 3 left

To show all of John the Rippers options simply type-

./john

If you only have a small password file, say less than 100 users then any passwords that remain uncracked after 24-48 hours can be considered to be reasonably secure. Most of the really insecure passwords will be cracked in the first hour. If you can crack none of the passwords after a week your users certainly deserve a pat on the back in the very least, if not an evening at your favourite watering hole at the IT departments expense.