Let me tell you a story. Once upon a time, UNIX passwords were stored in the file /etc/passwd. This file stored, among other things, the encrypted passwords for each user on the system. Now if some shady individual wanted to attempt to gain access to someone else's account, all they'd have to do is snag a copy of /etc/passwd. Once they had that file, they could brute force the password out by encrypting random strings until the encrypted result matched what was in the passwd file.

For a variety of reasons, that's a bad thing to have happen. Luckily, UNIX has a concept of permissions that allow files to be protected from random people reading them. So we could just remove everyone's read permissions on /etc/passwd except for root and problem solved, right? Well, not exactly. It turns out that lots of programs need access to the passwd file. This includes the login programs, password changing program, and a variety of account maintainence utilities. In addition, passwd stores lots of useful information that everyone might want.

If only there were some way to hide the encrypted passwords from prying individuals while at the same time allowing everyone the access they need to the other account information. Enter the shadow password suite. This suite of programs allows us to move all the encrypted passwords into the /etc/shadow file, which is only readable by root. All that other helpful account information is left in the world readable /etc/passwd file. In the password field of /etc/passwd for each user, an "x" is entered. This tells all the programs that need to get the password to go look at the shadow file.

That involves some goofy permission magic that I don't really understand. However, the result is that we can move the encrypted passwords into a very restricted file and leave that useful stuff in the world readable file. So, the bad guys can't read your encrypted passwords.

Here is the format of one line of the /etc/shadow file. I'm reading this line off a Linux system though I'm told it is the same (or very similar) on Solaris.

chris:$1$w9bsw/N9$UWLr2bRER6YyBS.CAEp7R.:11055:0:99999:7:::

Fields are delimited by colons and are as follows:

  1. user name
  2. encrypted password (I made one up just for this exercise)
  3. days since the password was last changed, expressed as days since the Epoch
  4. days before the password may be changed again (0 = change at any time)
  5. days after which the password must be changed (99999 = password never expires)
  6. days before password expiration that the user will be notified
  7. days after expiration that the account will be disabled
  8. days the account has been expired, expressed as days since the Epoch
  9. reserved

As you can see, most of those fields deal with password expiration and what to do to the account after that happens. As you can also see, most of those fields are optional. I usually opt out of them too.

In addition, modern Linux distributions (please enlighten me about other flavors of Unix) encrypt passwords using MD5 instead of the weak algorithm (DES) used before. If you get the scrambled text, you can still perform a dictionary attack on it, but most definitely not a brute force one. The sample Iconoplast listed has a MD5-encrypted password.

Actually, encrypt is not the right word -- MD5 is a hash function.

Log in or register to write something here or to contact authors.