Password Policies
| If your users have insecure passwords, all the other security measures you might take may well be moot. Probably the most responsible thing you can do as the administrator of a FreeBSD system is to institute a password policy, requiring (or at least encouraging) your users to use passwords that cannot be easily guessed or decoded. Users frequently find passwords inconvenient, and strict password policies doubly so. If allowed, a user will try to use his username, his telephone number, the server's hostname, a word such as "password," or strings of convenient-to-type characters, such as repeated letters or numbers. If you choose to expire users' passwords after some period, the first thing a user will try, when prompted to choose a new password, is to reuse the password from the previous period. However, an axiom of security is that "convenience and security are mutually exclusive," meaning that to increase one, you must sacrifice the other. Increased convenience brings about decreased security. There's no easy way around that fact for you or for your users. When a user chooses a password using the system's passwd program or a script that calls the same routines that passwd uses, a few loose checks are performed. By default, passwords must be at least six characters in length, but that's about the only built-in measure that prevents people from choosing weak passwords. You can use the following techniques to take your password policy to the next level. Tip An ideal password is at least eight characters long (the longer the better, actually), and contains a mixture of capital and lowercase letters, numbers, and punctuation marks or meta-characters. To keep your system security strong, you must ensure that users follow these guidelines when picking a password with the passwd program in FreeBSD. Although the only password security measure currently enforced by the default passwd program is that passwords must be at least six characters long, the FreeBSD development community is working to incorporate further weak-password checks into the passwd program. You learn how to use the login.conf program to set a minimum password length and to require periodic password updates in "Forcing Password Expiration," later in this chapter. Enforcing Secure Passwords with CrackThe first priority in maintaining secure user password practices is to prevent users from choosing insecure passwords in the first place. As of this writing, the best way to make sure your users aren't using easily guessable passwords is to periodically try to guess them yourself. A tool called Crack, available in the ports collection at /usr/ports/security/crack, helps you do just that. Although it may appear to be a "hacker" tool, Crack is primarily intended as a security-auditing tool for system administrators, allowing you to perform "dictionary" attacks (trying a plethora of English words as potential passwords) as well as a number of other commonly used "convenience" passwords: repeated strings, the user's login name, groups of numbers, and so on. Crack helps you determine which of your users are using insecure passwords. You can then contact these users directly and ask them to adhere to the password rules you set. You can build and install the Crack port using the instructions in Chapter 16, "Installing Additional Software." The new /usr/local/crack directory's permissions enable only root to list its contents or run any of its programs. To check your system's user database for weak passwords, go into /usr/local/crack and run the Crack program like this (note the capitalization): # ./Crack -fmt bsd /etc/master.passwdThe Crack program builds some utilities, compiles some dictionaries, and then launches its arsenal against /etc/master.passwd. Crack sends its output into runtime files that you can analyze with the Reporter program, as shown here: # ./Reporter -quiet ---- passwords cracked as of Sun Jan 14 12:17:41 EST 2001 ---- 979693112:Guessed frank [frank] Frank Jones [/etc/master.passwd /bin/tcsh] 979693187:Guessed joe [password] Joe User [/etc/master.passwd /usr/local/bin/bash] ---- done ----Crack reports only the users whose passwords were successfully guessed. In the sample output, the cracked passwords are shown in the first set of brackets; Frank's password is frank, and Joe's password is passwordboth very weak passwords that can be guessed by an attacker with little effort. You can then contact these users and remind them of the password policy, requiring them to change to stronger passwords. After you're done running Crack, clean up the runtime tools and output files with the following two commands: # make tidy # rm run/F-merged Note As FreeBSD continues to develop, it's highly likely that there will be support in the passwd program for automatic password-strength checking such as that done manually by Crack; in fact, the libraries that Crack uses are available at /usr/ports/security/cracklib. On systems such as Linux, cracklib has been developed into a Pluggable Authentication Module (PAM), a mechanism that FreeBSD supports as well (see man pam), but FreeBSD doesn't have cracklib support fully integrated into PAM as of this writing. For now, though, if you're an adventurous sort willing to work with source code and experimental software, and you're interested in incorporating the cracklib routines into the passwd program, you can learn how at http://www.kearneys.ca/~brent/FreeBSD/passwd42.html. Tip A tool similar to Crack, but with more extensive checking and faster operation, is John the Ripper (/usr/ports/security/john). It can be very useful in conjunction with Crack or on its own. Forcing Password ExpirationBy default, passwords in FreeBSD do not expire. However, one common part of a secure password policy is to require users to change their passwords every so often, with the expiration interval chosen by you. To do this in FreeBSD, you need to modify the /etc/login.conf file. This file controls system capabilities and behaviors, such as the number of allowed processes, the maximum allowed process size, the allowed number of simultaneous open files, and certain shell behaviors (learn more about this file in man login.conf). Each of these controls can be assigned to a "class" of users; you can assign users to classes with the chfn command (as you have seen in the "The /etc/passwd and /etc/master.passwd Files" section of Chapter 13, "Users, Groups, and Permissions"). By default, users aren't associated with any particular class, so the values in the default class apply to everybody:
The backslash (\) characters "escape" the line breaks, allowing you to specify all these properties on different lines, thus keeping the file readable. To set a password expiration date, you put an extra line into the default class, specifying the passwordtime property. The line can go into the block at any point, but the easiest place to add it is right at the top, between the class name and the first existing property line: default:\ :passwordtime=90d:\ :passwd_format=md5:\ :copyright=/etc/COPYRIGHT:\ :welcome=/etc/motd:\This example sets passwords to expire after 90 days. You can also use time values such as 2y (2 years), 6w (6 weeks), and 24h (24 hours). Now, because /etc/login.conf is a database that must be compiled into a hash table (as with the tables in /etc/mail, which you learned about in "Configuring Basic Email Services with Sendmail," in Chapter 25, "Configuring Email Services," and as with the /etc/master.passwd file and its corresponding hash table of user accounts), you must run the cap_mkdb program to generate the hash table and enable your changes: # cap_mkdb /etc/login.confFrom now on, the login procedures will require users to choose a new password every 90 days. Note that when the passwordtime property is set, passwd writes the time of the last password change into the sixth field of /etc/master.passwd: frank:$1$LXZkCuzD$7Oa8LyRf5jYOb.XrXiB3d.:1060:100::999066364:0:: /home/frank:/bin/tcsh Tip You can also use login.conf to alter the default minimum password length. This is done with the minpasswordlen value: :minpasswordlen=8:\ This sets the minimum acceptable password length to eight characters. Assigning Initial PasswordsWhen you're setting up a new user's account, it can be tempting to set a simple initial password, such as Temp123 or ChangeThis. This seemingly innocuous practice, however, can seriously compromise your system's securityespecially if you use the same temporary password for every new user you add. Fortunately, the adduser script provides you with the ability to assign randomly generated, nearly unguessable passwords to each new user you add to the system. In its default configuration, adduser will ask you during its questionnaire procedure what kind of password you want it to create; but you can specify that it should generate a random password for each user by adding the following line to your /etc/adduser.conf file: passwdtype=randomAlternatively, invoke the adduser command with the -w random option. When you use either of these techniques, a run of the adduser program (as you saw in Chapter 13) ends with output similar to the following: adduser: INFO: Successfully added (joe) to the user database. adduser: INFO: Password for (joe) is: cwwqAuSpwd0rYG Add another user? (yes/no): no Goodbye!There's little to no chance that a casual password-cracking program will guess the password cwwqAuSpwd0rYG. Now, however, your task is to make sure that Joe doesn't turn right around and set his password to "joe" or something equally trivial. One way to enforce this policy is to require onetime passwords that are good only for a single login session. Tip A tool for generating random passwords on demand is pwgen2, available in the ports in the sysutils category. It allows you to change users' passwords at any time, rather than just at user creation time, and gives you many flexible options for how the passwords should be created. Onetime Passwords with S/KeyIf you're really serious about password security, you can do what they do at government offices and super-secure businesses: You can assign onetime passwords to your users, shifting part of the security burden from your own shoulders onto those of your users. The idea is that each user gets a set of passwords (or a means to generate one on-demand), each of which are only good for a single login attempt. Onetime passwords are generated by the key program, which has variants on all major platforms, and there's even a platform-agnostic Java key calculator at http://www.cs.umd.edu/~harry/jotp/src.html. (FreeBSD uses MD4 for its calculations.) When the user attempts to log in, the server presents him with a "challenge" phrase and a number. The user then uses the key program and those input values to generate a password for that one login attempt and enters that password. This password is then never used again; at the next login attempt, he must generate a new password using the new number presented in the server's challenge. Onetime passwords are good candidates for use on systems in which you don't obligate your users to use SSH instead of Telnet (as we will discuss shortly). Because a new password has to be generated by the user with the key program on a local system, with the user feeding into it the server's challenge phrase and the user's own secret password, which is never transmitted over the wire (except during initial key setup), an eavesdropper can never get any useful data by sniffing the connection. Once the password is used once, it can't be used again. The user can transmit his onetime password in clear text without fear. Note S/Key is as much a tool for a security-conscious user as it is a way for the administrator to enforce good security practices. Many parts of S/Key setup (for example, the keyinit program) are the user's responsibility to maintain. If a user feels strongly about keeping her passwords private, she might choose to use onetime passwords, even if she has the option to do otherwise. However, this also means that a user is free to choose not to use onetime passwords if she doesn't have to. Let's say you want to make it so that the user Frank cannot log in with his usual UNIX password from a remote host but instead must use S/Key onetime passwords. While logged in to the server (preferably securely, as with SSH), he must use the keyinit program to set up S/Key authentication: # keyinit Adding frank: Reminder - Only use this method if you are directly connected. If you are using telnet or rlogin exit with no password and use keyinit -s. Enter secret password: Again secret password: ID frank s/key is 99 st28077 COL APT HELM TAB DRY TRIMNote If Frank is not securely connected to the server (as with a clear-text Telnet connection), he ought to use keyinit -s, which increases security by separating the keyinit and key steps. Without the -s, keyinit incorporates the key program into its own operation. Frank enters his secret key-generating password (which is used only for calculating S/Key onetime passwords and shouldn't be the same as his UNIX password) and transmits it over the network to the server. If the connection isn't secure, the secret password is susceptible to interception, making any further attempts at security moot. If Frank uses the -s option, he must first use the key program locallyon his own Windows, Macintosh, or UNIX machineto generate a password without exposing his secret keygenerating password to the network. He then enters this password into keyinit at the s/key access password: prompt (which only appears if the -s option is used). After Frank has used keyinit to set up his S/Key mechanism and has added an entry for his login to /etc/skeykeys, you must create the file /etc/skey.access (if it doesn't already exist) and add the following line: deny user frankThe /etc/skey.access file tells FreeBSD under what conditions a remote user is permitted to use his regular UNIX password, and under what conditions he must use an S/Key onetime password. A line in skey.access specifies a rule beginning with permit (allowing either an S/Key or UNIX password) or deny (requiring an S/Key password), followed by as many conditions as you like. These conditions can specify certain users, groups, remote hostnames or networks, or login terminals (you can read a full description of the conditions in man skey.access). The sample line you just saw requires that when Frank tries to log in, only an S/Key password is permittednot his UNIX password. The next time Frank uses Telnet to connect to your system, his login prompt will look like this: # telnet stripes.example.com Trying 64.41.131.102... Connected to stripes.example.com. Escape character is '^]'. FreeBSD/i386 (stripes.example.com) (ttyp2) login: frank s/key 99 st28077 Password:Note As mentioned earlier, S/Key provides a way to make even clear-text Telnet logins secure. However, if you have a tight security policy, you should require your users to use SSH and disable Telnet logins altogether. If Frank were to use SSH to connect, the S/Key behavior would be the same as in the example, although the output lines would look somewhat different. Frank must now use the key program (or its equivalent) on his own machine to figure out what password to enter. He has to feed into it the challenge information presented by the server: the iteration count (99 in this case, meaning that there are 99 logins left before Frank must run keyinit again), followed by the "seed" string (st28077 here, the same as you saw in the keyinit example). These numbers, combined with Frank's secret password, generate an S/Key password made up of six short, uppercase English words: # key 99 st28077 Reminder - Do not use this program while logged in via telnet or rlogin. Enter secret password: COL APT HELM TAB DRY TRIMFrank now enters this string of words as his password and is granted access. An attacker, if he intercepted the words, would be out of luckthey only went across the wire once (on the way to the login prompt). The next time the system asks for Frank's S/Key password, the iteration number will be 98, and the password will be different. The iteration keeps counting down until it hits zero, at which time Frank must run keyinit again to set the counter back to 99; otherwise, he will be denied access and you'll have to get involved (by changing his rule in /etc/skey.access from deny to permit until he's reinitialized S/Key). Tip If he wants, Frank can generate multiple keys at once by using key with the -n option. He can then print out these keys and take them with him if that's more convenient or secure for him: # key -n 5 50 st28077 Reminder - Do not use this program while logged in via telnet or rlogin. Enter secret password: 41: SHOT YOU BIEN GIN JUDD AS 42: CHOW AVIS DOES EMIT FLAM WORK 43: DOCK ATE ANN WAS JOCK OAT 44: WALE AWL ELK LETS AWK WALE 45: GIFT BERT ROD GRIN YANG EASTThis practice is often observed by high-sensitivity employers such as defense contractors, where computers are isolated behind "air gaps" and their capabilities are highly restricted. The S/Key password challenge is also issued as part of the su command, helping to prevent the actual root password from being transmitted over the network at any time. To turn off S/Key for a user, remove that user's entry from /etc/skeykeys and any mention of him from /etc/skey.access. KerberosOne last authentication method that deserves mention is Kerberos. Developed as a centralized login-management system at the Athena cluster at MIT, Kerberos provides a way for users to authenticate with a central server on a network and be issued "tickets" for performing tasks such as Telnet, FTP, POP3, and NFS, without having to log in each time. As long as the hosts on your network between which you're running traffic support Kerberos and subscribe to the master server, the Kerberos subsystem takes care of all the authentication chores for you. FreeBSD allows you to set up a Kerberos master server to which other hosts in the network subscribe, or to simply support Kerberos in a network where it's already running. Until fairly recently, Kerberos has been a scheme that was really useful only in legacy situations or at MIT. Its usefulness is in streamlining often-used tasks in large LANs, such as those found at universities or hierarchical enterprise networks, and there aren't many situations left where Kerberos is especially important in today's networking atmosphere. It's less a security measure than a way of eliminating unnecessary work in pure UNIX environments. However, because many enterprise networks use Kerberos to provide centralized, encrypted login services, and because Windows 2000/XP/2003's security model is largely tied together with Kerberos (albeit a somewhat modified version), it's once again becoming increasingly important and ubiquitous. You may need to set up your FreeBSD machine to integrate with it. If you want to enable Kerberos in FreeBSD, you can do so. kerberos_server_enable="YES" in /etc/rc.conf will start up the services that manage a master Kerberos server; if you're working with an existing master server, you can uncomment the appropriate lines in /etc/pam.conf to enable centralized authentication for the services that support it. Here's an example: login auth sufficient pam_kerberosIV.so try_first_passYou can read more about Kerberos in the man kerberos page and in the online FreeBSD Handbook (http://www.freebsd.org/handbook). |
/X11R6/bin ~/bin:\ :nologin=/var/run/nologin:\ :cputime=unlimited:\ :datasize=unlimited:\ :stacksize=unlimited:\ :memorylocked=unlimited:\ :memoryuse=unlimited:\ :filesize=unlimited:\ :coredumpsize=unlimited:\ :openfiles=unlimited:\ :maxproc=unlimited:\ :sbsize=unlimited:\ :priority=0:\ :ignoretime@:\ :umask=022: