 | Chapter 8 Defending Your Accounts |  |
| Chapter 8 Defending Your Accounts | |
If you're a system administrator and you are stuck using conventional UNIX passwords, then you will find this section helpful. It describes a number of techniques that you can use to limit the danger of conventional passwords on your computer.
Getting users to pick good passwords can be very difficult. You can tell users horror stories and you can threaten them, but some users will always pick easy-to-guess passwords. Because a single user with a bad password can compromise the security of the entire system, some UNIX administrators assign passwords to users directly rather than letting users choose their own.
To prevent users from changing their own passwords, all that you have to do is to change the permissions on the /bin/passwd program that changes people's passwords.[14] Making the program executable only by people in the staff group, for example, will still allow staff members to change their own passwords, but will prevent other people from doing so:
[14] This technique requires changing permissions on any other password-changing software, such as yppasswd and nispasswd.
# chgrp staff /bin/passwd # chmod 4750 /bin/passwd
Use this approach only if staff members are available 24 hours a day. Otherwise, if a user discovers that someone has been using her account, or if she accidentally discloses her password, the user is powerless to safeguard the account until she has contacted someone on staff.
Some versions of UNIX may have an administrator command that will allow you to prevent selected users from changing their passwords.[15] Thus, you do not need to change the permissions on the passwd program. You only need to disable the capability for those users who cannot be trusted to set good passwords on their own.
[15] On AIX, the root user can prevent ordinary users from changing their passwords by running the following: pwdadm -f ADMIN user or by editing /etc/security/passwd.
For example, in SVR4 UNIX, you can prevent a user from changing her password by setting the aging parameters appropriately (we discuss password aging in a few more pages). For example, to prevent Kevin from changing his password, you might use the command:
# passwd -n 60 -x 50 kevin
Note, however, that Kevin's password will expire in 50 days and will need to be reset by someone with superuser access.
You can easily strengthen the passwd program to disallow users from picking easy-to-guess passwords - such as those based on the user's own name, other accounts on the system, or on a word in the UNIX dictionary. So far, however, many UNIX vendors have not made the necessary modifications to their software. There are some freeware packages available on the net, including npasswd and passwd+, which can be used for this purpose; both are available at popular FTP archives, including coast.cs.purdue.edu. Another popular system is anlpasswd, which has some advantages over npasswd and passwd+, and can be found at info.mcs.anl.gov.
Some versions of UNIX, most notably the Linux operating system, come supplied with npasswd. Other vendors would do well to follow this example.
An approach that is present in many versions of UNIX involves putting constraints on the passwords that users can select. Normally, this approach is controlled by some parameters accessed through the system administration interface. These settings allow the administrator to set the minimum password length, the number of nonalphabetic characters allowed, and so on. You might even be able to specify these settings per user, as well as per system.
One UNIX system that combines all these features in addition to password aging is AIX. By editing the security profile via the smit management tool, the administrator can set any or all of the following for all users or individually for each user (IBM's recommended settings are given for each):
The minimum and maximum age of passwords, in weeks (0, 12)
The number of days of warning to give before expiring a password (14)
The minimum length of the new password (6)
The minimum number of alphabetic and non-alphabetic characters that must be present in the new password (1, 1)
The maximum number of repeated characters allowed in the new password (3)
The minimum number of characters that must be different from those in the previous password (3)
The number of weeks before a password can be used again (26)
The number of new passwords that must be selected and used before an old password can be used again (8)
The name of a file of prohibited words that cannot be selected as passwords
A list of programs that can be run to check the password choice for acceptability
This list is the most comprehensive group of "settable" password constraints that we have seen. If you are using traditional passwords, having (and properly using!) options such as these can significantly improve the security of your passwords.
A less drastic approach than preventing users from picking their own passwords is to run a program periodically to scan the /etc/passwd file for users with passwords that are easy to guess. Such programs, called password crackers, are (unfortunately?) identical to the programs that bad guys use to break into systems. The best of these crackers is a program called Crack. (We tell you in Appendix E, where to get it.) If you don't (or can't) use shadow password files, you definitely want to get and use the Crack program on your password file...because one of your users or an attacker will most certainly do so.
NOTE: Before you run a password cracker on your system, be sure that you are authorized to do so. You may wish to get the authorization in writing. Running a password cracker may give the impression that you are attempting to break into a particular computer. Unless you have proof that you were authorized to run the program, you may find yourself facing unpleasant administrative actions or possibly even prosecution for computer crime.
To understand how a password-cracking program works, consider this program, which simply scans for accounts that have the same password as their username. From Chapter 3, remember that such accounts are known as "Joes." The program must be run as root if you have shadow password files installed on your system:
/*
* joetest.c:
*
* Scan for "joe" accounts -- accounts with the same username
*and password.
*/
#include <stdio.h>
#include <pwd.h>
int main(int argc,char **argv)
{
struct passwd *pw;
while(pw=getpwent() ){
char *crypt();
char *result;
result = crypt(pw->pw_name,pw->pw_passwd);
if(!strcmp(result,pw->pw_passwd)){
printf("%s is a joe\n",pw->pw_name);
}
}
exit(0);
}To show you the advantages of the Perl programming language, we have rewritten this program:
#!/usr/local/bin/perl
#
# joetest
#
while (($name,$passwd) = getpwent) {
print "$name is a joe\n" if (crypt($name,$passwd) eq $passwd);
}To further demonstrate the power of Perl, consider the following script, which only runs under Perl5:
#!/usr/local/bin/perl
#
# super joetest
#
while (($name,$passwd) = getpwent) {
print "$name has no password\n" if !$passwd;
print "$name is a joe\n" if (crypt($name,$passwd) eq $passwd);
print "$name is a JOE\n" if (crypt(uc($name), $passwd) eq $passwd);
print "$name is a Joe\n" if (crypt(ucfirst($name), $passwd)
eq $passwd);
print "$name is a eoj\n" if (crypt(scalar reverse $name, $passwd)
eq $passwd);
}If you have the time, type in the above program and run it. You might be surprised to find a Joe or two on your system. Or simply get Crack, which will scan for these possibilities, and a whole lot more.
Because password crackers are used both by legitimate system administrators and computer criminals, they present an interesting problem: if you run the program, a criminal might find its results and use them to break into your system! And, if the program you're running is particularly efficient, it may be stolen and used against you. Furthermore, the program you're using could always have more bugs or have been modified so that it doesn't report some bad passwords that may be present: instead, such passwords might be silently sent by electronic mail to an anonymous repository in Finland.
Instead of running a password cracker, you should prevent users from picking bad passwords in the first place. Nevertheless, this goal is not always reachable. For this reason, many system administrators run password crackers on a regular basis. If you run a program like Crack and find a bad password, you should disable the account immediately, because an attacker could also find it.
NOTE: If you run a password cracker and don't find any weak passwords, you shouldn't assume that there are none to find! You might not have as extensive a set of dictionaries as the people working against you: while your program reports no weak passwords found, outsiders might still be busy logging in using cracked passwords found with their Inuit, Basque, and Middle Druid dictionaries. Or an attacker may have booby-trapped your copy of Crack, so that discovered passwords are not reported but are sent to a computer in New Zealand for archiving. For these reasons, use password cracking in conjunction with user education, rather than as an alternative to it.
Under many newer versions of UNIX,
you can prevent users from choosing their own passwords altogether.
Instead, the passwd program runs a password
generator that produces pronounceable passwords. To force users
to use the password generator under some versions of System V UNIX,
you select the "Accounts
DefaultsPasswords"
menu from within the sysadmsh administrative program.
Most users don't like passwords that are generated by password generators: despite claims of the program's authors, the passwords really aren't that easy to remember. Besides, most users would much rather pick a password that is personally significant to them. Unfortunately, these passwords are also the ones that are easiest to guess.
Two more problems with generated passwords are that users frequently write them down to remember them, and that the password generator programs themselves can be maliciously modified to generate "known" passwords.
There are several freely available password generators that you can download and install on your system. The mkpasswd program by Don Libes is one such program, and it can be found in most of the online archives mentioned in Appendix E.
Instead of using password generators, you may want to install password "advisors" - programs that examine user choices for passwords and inform the users if the passwords are weak. There are commercial programs that do this procedure, such as password coach by Baseline Software, and various freeware and shareware filters such as passwd+. In general, these products may do comparisons against dictionaries and heuristics to determine if the candidate password is weak. However, note that these products suffer from the same set of drawbacks as password crackers - they can be modified to secretly record the passwords, and their knowledge base may be smaller than that used by potential adversaries. If you use an "advisor," don't be complacent!
When the UNIX password system was devised, the simple security provided by the salt was enough. Computers were slow (by present standards), and hard disks were small. At the rate of one password encryption per second, the system would have taken three years and three months to encrypt the entire 25,000-word UNIX spelling dictionary with every one of the 4096 different salts. Simply holding the database would require more than 10 gigabytes of storage - well beyond the capacity of typical UNIX platforms.
The advantage to a computer criminal of such a database, however, would be immense. Such a database would reduce the time to do an exhaustive key search for a password from seven hours to a few seconds. Finding accounts on a computer that had weak passwords would suddenly become a simple matter.
Today, many of the original assumptions about the difficulty of encrypting passwords have broken down. For starters, the time necessary to calculate an encrypted password has shrunk dramatically. Modern workstations can perform up to several thousand password encryptions per second. Versions of crypt developed for supercomputers can encrypt tens of thousands of passwords in the same amount of time. Now you can even store a database of every word in the UNIX spelling dictionary encrypted with every possible salt on a single 10 gigabyte hard disk drive, or on a few high-density CD-ROMs.
Because of these developments, placing even encrypted passwords in the world-readable /etc/passwd file is no longer secure.[16] There is still no danger that an attacker can decrypt the passwords actually stored - the danger is simply that an attacker could copy your password file and then systematically search it for weak passwords. As a result, numerous vendors have introduced shadow password files.[17] UNIX systems that offer at least so-called C2-level security features have shadow password files, or the capability to install them.
[16] The /etc/passwd file must be world readable, because many, many programs need to consult it for UID to account name mappings, home directories, and username information. Changing the permissions breaks quite a few essential and convenient services.
[17] Shadow password files have been a standard part of AT&T UNIX since the introduction of SVR4. A number of add-on shadow password systems are available for other versions of UNIX; installing them requires having the source code to your UNIX system.
Shadow password files hold the same encrypted passwords as the regular UNIX password file: they simply prevent users from reading each other's encrypted passwords. Shadow files are protected so that they cannot be read by regular users; they can be read, however, by the setuid programs that legitimately need access. (For instance, SVR4 uses the file /etc/shadow, with protected mode 400, and owned by root; SunOS uses the file /etc/security/passwd.adjunct, where /etc/security is mode 700.) The regular /etc/passwd file has special placeholders in the password field instead of the regular encrypted values. Some systems substitute a special flag value, while others have random character strings that look like regular encrypted passwords: would-be crackers can then burn a lot of CPU cycles trying dictionary attacks on random strings.
If your system does not have shadow passwords, then you should take extra precautions to ensure that the /etc/passwd file cannot be read anonymously, either over the network or with the UUCP system. (How to do this is described in Chapter 15, UUCP, and Chapter 17.)
If you use shadow password files, you should be sure that there are no backup copies of the shadow password file that are publicly readable elsewhere on your system. Copies of passwd are sometimes left (often in /tmp or /usr/tmp) as editor backup files and by programs that install new system software. A good way to avoid leaving copies of your password files on your system is to avoid editing them with a text editor, or to exercise special care when doing so.
Some UNIX systems allow the system administrator to set a "lifetime" for passwords.[18] With these systems, users whose passwords are older than the time allowed are forced to change their passwords the next time they log in. If a user's password is exceptionally old, the system may prevent the user from logging in altogether.
[18] Different systems use different procedures for password aging. For a description of how to set password lifetimes on your system, consult your system documentation.
Password aging can improve security. Even if a password is learned by an attacker and the account is surreptitiously used, that password will eventually be changed. Password aging can also help you discover when people have access to passwords and accounts that aren't properly registered. In one case we know about, when a computer center started password aging, four users suddenly discovered that they were all using the same account - without each other's knowledge! The account's password had simply not been changed for years, and the users had all been working in different subdirectories.
Users sometimes defeat password aging systems by changing an expired password to a new password and then back to the old password. A few password aging systems check for this type of abuse by keeping track of old and invalid passwords. Others prevent it by setting a minimum lifetime on the new password. Thus, if the password is changed, the user is forced to use it for at least a week or two before it can be changed again - presumably back to the old standby.[19] If you use password aging, you should explain to your users why it is important for them to avoid reusing old passwords.
[19] This is a bad idea, even though it is common on many SVR4 systems. It prevents the user from changing a password if it has been compromised, and it will not prevent a user from cycling between two favorite passwords again and again.
Under SVR4, you can set password aging using the -n (minimum days before the password can be change) and -x (maximum number of days) options (e.g., passwd -n 7 -x 42 sally). Setting the aging value to -1 disables aging.
NOTE: Do not use the -n option with the password aging command! Configuring your system so that users are prevented from changing their password is stupid. Users can accidently disclose their passwords to others - for example, they might say their new password out loud when they are typing it in for the first time. If users are required to wait a minimum time before changing their passwords again, then their accounts will be vulnerable.
Password aging should not be taken to extremes. Forcing users to change their passwords more often than once every few months is probably not helpful. If users change their passwords so often that they find it difficult to remember what their current passwords are, they'll probably write these passwords down. Imagine a system that requires users to change their passwords every day. Expiration times that are too short may make the security worse, rather than better. Furthermore, it engenders discontent - feelings that the security mechanisms are annoying rather than reasonable. You may have good passwords, but having users who are constantly angry about the security measures in place probably negates any benefits gained.
On the other hand, if you want your users to change their passwords every minute, or every time that they log in, then you probably want to be using a one-time password system, such as those described in Section 8.7.1, "Integrating One-time Passwords with UNIXearlier in this chapter.
If you have the source code to your system, you can alter the crypt() library function to dramatically improve the resistance of your computer to password cracking. Here are some techniques you might employ:
Change the number of encryption rounds from 25 to something over 200. This change will make the encryption routine operate more slowly, which is good. More importantly, it will make encrypted passwords generated on your computer different from passwords generated on other systems. This foils an attacker who obtains a copy of your /etc/passwd file and tries to crack it on a remote computer using standard software.
Add a counter to the crypt() library call that keeps track of how many times it has been called within a single process. If a user's program calls it more than 5 or 10 times, log that fact with syslog, being sure to report the user's login name, tty and other pertinent information. Then start returning the wrong values![20]
[20] Many sites feel uncomfortable with this advice to modify a system library to return wrong values. However, in our experience, few (if any) programs need to run crypt() more than a few times in a single process unless those processes are attempting to crack passwords. On the other hand, when we have worked with sites that have had problems with password cracking, those problems have stopped immediately when the crypt() routine was modified to behave in this manner. If you feel uncomfortable having some programs silently fail, you may wish to end their silence, and have them send email to the system administrator or log a syslogmessage when the crypt() routine is run more than a few times.
If you decide to implement this approach, there are some issues to be aware of:
If your system uses shared libraries, be sure to update the crypt() in the shared library; otherwise, some commands may not work properly.
If your system does not use shared libraries, be sure to update the crypt() function in your file libc.a, so that people who write programs that use crypt() will get the modified version.
Be sure to re-link every program that uses crypt() so that they all get the new version of the routine. On most UNIX systems, that means generating new versions of (at least) the following programs:
/bin/login | /usr/sbin/in.rexecd |
/bin/su | /usr/sbin/in.rlogind |
/bin/passwd | /usr/sbin/in.rshd |
/usr/sbin/in.ftpd |
Some programs legitimately need to call the crypt() routine more than 10 times in a single process. For example, the server of a multiuser game program, which uses passwords to protect user characters, would need to call crypt() if it stored the passwords in an encrypted form (another good idea). For programs like these, you will need to provide a means for them to run with a version of the crypt() function that allows the function to be run an unlimited number of times.
Do these techniques work? Absolutely. A few years ago, there was a computer at MIT on which guest accounts were routinely given away to members of the local community. Every now and then, somebody would use one of those guest accounts to grab a copy of the password file, crack it, and then trash other people's files. (This system didn't have shadow passwords either.) The day after the above modifications were installed in the system's crypt() library, the break-ins stopped and the system's administrators were able to figure out who was the source of the mischief. Eventually, though, the system administrators gave up on modifications and went back to the standard crypt() function. That's because changing your crypt() has some serious drawbacks:
The passwords in your /etc/passwd file will no longer be compatible with an unaltered system,[21] and you won't be able to trade /etc/passwd entries with other computers.
[21] This may be an advantage under certain circumstances. Being unable to trade encrypted passwords means being unable to have "bad" passwords on a computer that were generated on another machine. This is especially an issue if you modify your passwd program to reject bad passwords. On a recent sweep of numerous computers at AT&T, one set of machines was found to have uncrackable passwords, except for the passwords of two accounts that had been copied from other machines.
If your site transfers /etc/passwd entries between machines as ways of transferring accounts, then you will need to have the same crypt() modifications on each machine.
If you use NIS or NIS+, then you must use the same crypt() algorithm on all of the UNIX machines on your network.
You'll need to install your changes every time the software is updated, and if you cease to have access to the source, all of your users will have to set new passwords to access the system.
This method depends on attackers not knowing the exact number of rounds used in the encryption. If they discover that you're using 26 rounds instead of 25, for example, they can modify their own password-breaking software and attack your system as before. (However, this scenario is unlikely to happen in most environments; the cracker is more likely to try to break into another computer - hardly a drawback at all!)
If an insider knows both his cleartext password and the encrypted version, he can also determine experimentally how the algorithm was changed.
NOTE: While increasing the number of rounds that the encryption algorithm performs is a relatively safe operation, don't alter the algorithm used in the actual password mechanism unless you are very, very confident that you know what you are doing. It is very easy to make a change you think is adding complexity, only to make things much simpler for an attacker who understands the algorithm better than you do.
If a user is going away for a few weeks or longer, you may wish to prevent direct logins to that user's account so the account won't be used by someone else.
As mentioned earlier, one easy way to prevent logins is to insert an asterisk (*) before the first character of the user's password in the /etc/passwd file or shadow password file.[22] The asterisk will prevent the user from logging in, because the user's password will no longer encrypt to match the password stored in /etc/passwd, and the user won't know what's wrong. To re-enable the account with the same password, simply remove the asterisk.
[22] This method of changing a user's password is not sufficient if the user has a .rhosts file or can rlogin from a computer in your computer's /etc/hosts.equiv file. It also will not stop the execution of programs run by the cron or at commands.
For example, here is the /etc/passwd entry for a regular account:
omega:eH5/.mj7NB3dx:315:1966:Omega Agemo:/u/omega:/bin/csh
Here is the same account, with direct logins prevented:
omega:*eH5/.mj7NB3dx:315:1966:Omega Agemo:/u/omega:/bin/csh
Under SVR4, you can accomplish the same thing by using the -l option to the passwd command, (e.g., passwd -l omega).
You should be sure to check for at and cron jobs that are run by the user whose account you are disabling.
Note that the superuser can still su to the account. The section Section 8.5, "Protecting the root Account explains the details of protecting accounts in a variety of other ways. Briefly, we'd also suggest that you set the login shell equal to /bin/false, or to some program that logs attempts to use it. You should also consider changing the permissions on the user's home directory to mode 000 and changing the ownership to user root.
As the administrator, you may also want to set expiration and inactivity time-outs on accounts. This step means that accounts cease to be valid after a certain date unless renewed, or they cease to be usable unless a valid login occurs every so often. This last case is especially important in environments where you have a dynamic user population (as in a university) and it is difficult to monitor all of the accounts. We discussed this in greater detail earlier in this chapter.
As we described earlier in this chapter, you can give accounts almost any name you want. The choice of account names will usually be guided by a mixture of administrative convenience and user preference. You might prefer to call the accounts something mnemonic, so that users will be able to remember other usernames for electronic mail and other communications. This method is especially useful if you give your users access to Usenet and they intend to post news. A properly chosen username, such as paula, is more likely remembered by correspondents than is AC00045.
At the same time, you can achieve slightly better security by having nonobvious usernames. This method is a form of security through obscurity. If an attacker does not know a valid username at your site, she will have greater difficulty breaking in. If your users' account names are not known outside your site and are nonobvious, potential intruders have to guess the account names as well as the password. This strategy adds some additional complexity to the task of breaking in, especially if some of your users have weak passwords.
If you use obscure account names, you need a way to protect those account names from outsiders while still allowing your users to access electronic mail and participate in Usenet discussions. The way to do this is with aliasing.
If you configure one machine to be your central mail and news site, you can set your software to change all outgoing mail and news to contain an alias instead of the real account name. This is probably what you wish to do if you decide to install a firewall between your site and the outside network (see Chapter 21, Firewalls).
For example, your mailer could rewrite the From: line of outgoing messages to change a line that looks like this:
From: paula@home.acs.com
to look like this:
From: Paula.Harris@ACS.COM
This address is also the electronic mail address Paula would put on her business cards and correspondence. Incoming mail to those addresses would go through some form of alias resolution and be delivered to her account. You would also make similar configuration changes to the Usenet software. There is an additional advantage to aliasing - if an outsider knows the names of his correspondents but not their account names (or machine names), he can still get mail to them.
If you take this approach, other network services, such as finger and who, must similarly be modified or disabled.[23]
[23] Discussing all of the various mailers and news agents that are available and how to modify them to provide aliasing is beyond the scope of this book. We suggest that you consult the O'Reilly & Associates books on electronic mail and news to get this information.
Many large organizations use some form of aliasing. For example, mail to people at AT&T Bell Laboratories that's addressed to First.Last@att.com will usually be delivered to the right person.
|  | |
| 8.7 One-Time Passwords |  | 9. Integrity Management |