Cracking Passwords to Enhance Security01/24/2001
In last week's article, we looked at which parts of a password policy could be implemented by editing the
/etc/login.conf file on your FreeBSD system. This week, I want to look at some techniques that can be used to implement the rest of our sample policy.
/etc/login.conf, we were able to enforce a minimum password length and set an expiry date on passwords. While it does not enforce password lockout per se, your FreeBSD system does come with some built-in mechanisms that make it harder for a person to try to guess a password by repeatedly typing in different passwords.
Use your ALT Function keys to find a terminal with a login prompt. Let's log in as a user, but type in an incorrect password:
login: bogus Password: Login incorrect login:
Notice what happened here. When you typed in the password, none of your keystrokes were displayed to your screen; this is to help prevent passersby from noticing what password you are typing. Also, the "login incorrect" error message doesn't specify what is incorrect. That is, it won't tell you if the problem is an incorrect username or an incorrect password.
Since we were just given the login prompt back after the error message, let's keep trying to use an incorrect password. At your fourth bad attempt, you'll notice something different: it took a few seconds to get the login prompt back. At your fifth bad attempt, it should take about 6 seconds before you get your prompt back; at your sixth bad attempt, it should take about 9 seconds, and so on. This cycle will continue until you either have 10 bad attempts or you use up 300 seconds. At that point, your screen should look something like this:
FreeBSD/i386 (hostname) (ttyv4) login:
and the cycle starts all over again.
While you were making your bad password attempts, your FreeBSD system was keeping track of your actions. Use your ALT F1 keys to go to the console terminal; you should see messages similar to this:
Jan 14 9:43:23 hostname login: 8 LOGIN FAILURES ON ttyv4 Jan 14 9:44:52 hostname login: 2 LOGIN FAILURES ON ttyv4
To implement the rest of our sample password policy, we'll have to be a bit more creative. We wanted users to have at least one non-letter character in their password, not be allowed to use their username as their password, and not reuse any of their last ten passwords.
One way to accomplish this is to make users aware of the password policy, then use a utility that will tell you which users are selecting poor passwords. This method makes the users responsible for choosing passwords that follow the policy, and makes the administrator responsible for ensuring that the policy is being enforced.
But how can a utility view a user's password? Remember that passwords are not stored anywhere on your FreeBSD system. Instead, a hash is stored in the password database, and these hashes are in an encrypted format. Let's take a minute to define what a hash is and how it is created.
A hash is a string of characters, like a password, that has been scrambled by an encryption algorithm. That is, some form of complicated math was done on the string of characters to make it very hard to guess what the original string of characters was. As an example, one could apply an algorithm to the word "password" and end up with something like "$1$hnH/w50a$tPdv5HZRsDP46FtsW8eXH."
Good hashes contain something called a "salt." A salt is a set of random characters that are added to the original string of characters before they are encrypted. A simple example of a salt would be to add the time of day; for example, if I log in at 8:45 using the password "password," the string that would be encrypted could be "8pass45word." By adding this bit of randomness to the password, my hash will actually be different every time I log in, unless the only time I ever log in is at 8:45.
Whether a salt is used and what the salt actually is depends upon the operating system and the encryption algorithm being used. On your FreeBSD system, there is a function called
crypt that uses either the "DES" or the "MD5" encryption algorithms to encrypt passwords. If you're curious to see the technical details on how
crypt works, read
man 3 crypt. Don't be dismayed if you can't understand everything in this manpage; encryption is supposed to be cryptic. Also, don't confuse the utility
crypt(1) with the function
crypt(3). The utility is a very primitive way to encrypt data files, while the function is an elaborate mechanism used to create password hashes.
By definition, password hashes are "one-way" hashes. This means that if I apply the same encryption algorithm to the hash, I won't end up with the original password; instead, I'll just end up with a more scrambled hash. The only way to find the original password is to type in a password, encrypt it with the same algorithm, and compare the resultant hash. If the hash is different, I must have used the wrong password; if the hash is the same, I can assume that I've typed in the correct password.
Which brings us to password crackers. These are utilities that encrypt hundreds of thousands of passwords in order to compare the resulting hashes with the hashes in your password database. Password crackers do follow a certain logic as they'll try the most common passwords first; for example, they'll try the user's name forwards, backwards, and with a number, they'll try information in the user's GECOS field, and they'll try a list of common passwords such as "password" and "pass." Then they'll go through all of the words in the dictionary. Not surprisingly, these types of crackers are called "dictionary" password crackers. Some password crackers are called "brute-force" password crackers as they add a third step: they'll patiently try every keystroke combination possible until all the passwords have been cracked.
Pages: 1, 2