By Kurt Seifried [email protected]
Authentication is typically one of the two main lines of defense that systems and networks rely upon, so ensuring that your authentication subsystems are implemented correctly is important. The majority of Linux systems rely on usernames and passwords, while support for tokens, smartcards and other authentication systems are available they are still relatively rare. On top of this sits PAM, as far as I know all major vendors use PAM by default, so understanding how PAM works and using it correctly is very important.
"Pluggable Authentication Modules for Linux is a suite of shared libraries that enable the local system administrator to choose how applications authenticate users." Straight from the PAM documentation, I don't think I could have said it any better. But what does this actually mean? For example; take the program “login”, when a user connects to a tty (via a serial port or over the network) a program answers the call (getty for serial lines, telnet or SSH for network connections) and starts up a login program, login then typically requests a username, followed by a password, which it checks against the /etc/passwd file. This is all fine and dandy until you have a spiffy new digital card authentication system and want to use it. Well you will have to recompile login (and any other apps that will do authentication via the new method) so they support the new system. As you can imagine this is quite laborious and prone to errors.
PAM introduces a layer of middleware between the application and the actual authentication mechanism. Once a program is PAM'ified, any authentication methods PAM supports will be usable by the program. In addition to this PAM can handle account, and session data which is something normal authentication mechanisms don't do very well. For example using PAM you can easily disallow login access by normal users between 6pm and 6am, and when they do login you can have them authenticate via a retinal scanner. By default Red Hat systems are PAM aware, and newer versions of Debian are as well (see bellow for a table of PAM’ified systems). Thus on a system with PAM support all I have to do to implement shadow passwords is convert the password and group files; and possibly add one or two lines to some PAM config files (if they weren't already added). Essentially, PAM gives you a great deal of flexibility when handling user authentication, and will support other features in the future such as digital signatures with the only requirement being a PAM module or two to handle it. This kind of flexibility will be required if Linux is to be an enterprise-class operating system. Distributions that do not ship as "PAM-aware" can be made so but it requires a lot of effort (you must recompile all your programs with PAM support, install PAM, etc), it is probably easier to switch straight to a PAM'ified distribution if this will be a requirement. PAM usually comes with complete documentation, and if you are looking for a good overview you go http://www.sun.com/software/solaris/pam/.
Other benefits of a PAM aware system is that you can now make use of an NT domain to do your user authentication, meaning you can tie Linux workstations into an existing Microsoft based network without having to say buy NIS / NIS+ for NT and go through the hassle of installing that. As far as I know all modern Linux distributions have PAM support and default to it.
A PAM cryptocard module is available http://projects.jdimedia.nl/index.phtml?ID=crypto&L=&BROW=1&W=1260&H=886. Cryptocards are excellent for securing interactive logins since they do not require any special equipment on the client end, thus you can log in from a cybercafe for example with no fear of your password being stolen (since it changes each time you log in). Unfortunately Cryptocards tend to be expensive and require some user training, I would advise them primarily for installations with a higher need of security then "normal" or for infrastructure related servers and equipment (i.e. Authentication servers).
Smartcards can be used to sign and encrypt email as well as providing login services. The primary problem with smartcards however is that the client station needs a compatible card reader, the chances of finding these on a system outside of your office are slim indeed. A module to provide PAM support for smartcards is available http://www.linuxnet.com/apps.html.
SMB (Server Message Block) is incredibly popular protocol for the simple reason Microsoft has choosen to use it as their primary protocol for Windows 9x and NT (it is also supported in 2000). Many sites have existing NT infrastructures, adding Linux servers that require their own authentications infrastructure can be quite troublesome. Fortunately you can authenticate on Linux machines against SMB servers, packages are available http://rpmfind.net/linux/rpm2html/search.php?query=pam_smb and the primary site is http://www.csn.ul.ie/~airlied/pam_smb/. You can also install SAMBA on the machine and use this to authenticate but for workstations the PAM module is much more appropriate.
Authentication services such as NIS and Kerberos are covered in the network servers section of the LASG here. Generally speaking they are easy to implement client side on modern Linux distributions, during install you are often given the choice of Kerberos, LDAP or NIS+ passwords and their related settings. Setting up the servers however is another matter.
In all UNIX-like operating systems there are several constants, and one of them is the file /etc/passwd and how it works. For user authentication to work properly you need (minimally) some sort of file(s) with UID to username mappings, GID to groupname mappings, passwords for the users, and other misc. info. The problem with this is that everyone needs access to the passwd file, every time you do an ls it gets checked, so how do you store all those passwords safely, yet keep them world readable? For many years the solution has been quite simple and effective, simply hash the passwords, and store the hash, when a user needs to authenticate take the password they enter it, hash it, and if it matches then it was obviously the same password. The problem with this is that computing power has grown enormously and I can now take a copy of your passwd file, and try to brute force it open in a reasonable amount of time (assuming you use a poor hash system, or weak passwords).
Using a hash such as MD5 or blowfish significantly increases the amount of computing power needed to execute a brute force attack, but there are two large problems with switching from the traditional crypt hash. The first is compatibility, if you use NIS or NIS+ with systems such as Solaris using a different hash then crypt will break authentication, obviously a problem. The other problem is that no matter how strong a hash you use poor passwords (such as the username or "dog") will still be easily discovered. If possible you should use a better hash, but if this is not possible then there is another solution.
User account data is stored in /etc/passwd traditionally, but the actual password hashes and related data (password expiry, etc.) is stored in /etc/shadow, a file only readable by root. Programs that need to check a password can either run as root or use a setuid or setgid wrapper program (like PAM provides) to check the password, the only way to get access to /etc/shadow requires root privileges. There have been problems in past with setuid programs that read /etc/shadow leaking information, however these are relatively rare (and you are no worse off then storing passwords in a world readable location).
Several OS's take the first solution, Linux has implemented the second for quite a while now. Because most vendors rely on PAM for authentication services, implementing a new authentication scheme is relatively simple, all you need to do it add a PAM module that understands the new authentication scheme and edit the PAM config file for whichever program (say login) uses it. Now for an attacker to look at the hashed passwords they must go to quite a bit more effort then simply copying the /etc/passwd file.
In Linux the passwords are stored in a hashed format, however this does not make them irretrievable, chances are you cannot reverse engineer the password from the resulting hash, however you can hash a list of words and compare them. If the results match then you have found the password (the chances of a different word hashing to the same value as another are slim), this is why good passwords are critical, and dictionary based words are a terrible idea. Even with a shadow passwords file the passwords are still accessible by the root user, and if you have improperly written scripts or programs that run as root (say a www based CGI script) the password file may be retrieved by attackers. The majority of current password cracking software also allows running on multiple hosts in parallel to speed things up.
Most modern Linux distributions use MD5 hashed passwords at a minimum (notable exceptions are SuSE and Debian which default to crypt for backwards compatibility with NIS and the like). In any event password crackers will usually catch poor passwords or dictionary based passwords quickly. As well on modern systems passwords are protected in shadow password files, if an attacker has access to this file chances are they have sufficient privilege to do other things to compromise the system.
VCU (Velocity Cracking Utilities) is a windows based programs to aid in cracking passwords, “VCU attempts to make the cracking of passwords a simple task for computer users of any experience level.”. You can download it http://packetstormsecurity.org/groups/wiltered_fire/NEW/vcu/
This is something many people don’t think about much. How can you securely store passwords? The most obvious method is to memorize them, this however has it’s drawbacks, if you administer 30 different sites you generally want to have 30 different passwords, and a good password is 8+ characters in length and generally not the easiest thing to remember. This leads to many people using the same passwords on several systems (come on, admit it). One of the easiest methods is to write passwords down. This is usually a BIG NO-NO; you’d be surprised what people find lying around, and what they find if they are looking for it. A better option is to store passwords in an encrypted format, usually electronically on your computer or palm pilot, this way you only have to remember one password to unlock the rest which you can then use. Something as simple as PGP or GnuPG can be used to accomplish this. If you can afford it using authentication tokens or smartcards are a good way to reduce the number of passwords you must memorize.
Many of these programs have been found to contain flaws, I advise using them with caution.
Strip is a palm pilot program for storing passwords securely and can also be used to generate passwords. It is GNU licensed and available http://www.zetetic.net/products.html. The generation function is flawed and should not be used.
Last updated on 4/10/2001
Copyright Kurt Seifried 2001 [email protected]