How to securely use passwords as an authentication mechanism for Unix systems is a heavily debated issue. Frankly, this isn't what should be debated, but rather the debate should focus on which alternatives to passwords should be implemented as an authentication mechanism. That aside, many sites, (including various hosts for which I am the system administrator) continue to use passwords as a form of authentication. The purpose of this document is to remind the reader of some of the problems with using passwords for authentication, and steps which can be taken to address some of these problems.
It should be noted that nothing presented here will suddenly make passwords a strong authentication mechanism. Rather, it will help to reduce some of the risk involved with using passwords for authentication within a controlled environment. Apply the information presented here carefully. If you're using passwords for authentication, you should certainly consider implementing some better mechanism, but in the meantime, if you carefully consider (and address) the risks, passwords can still be used with some degree of effectiveness.
The weakest link in the password chain is actually the user. Users can be coaxed into divulging their passwords, and users often resort to writing passwords down rather than remembering them. Unfortunately the only way to address this issue is to attempt to educate the users. The rest of this document examines some technical concerns with passwords.
The most important of these concerns is the fact that username and password pairs travelling over networks in plain-text, (such as when users connect via telnet, rlogin, or ftp), can easily be eavesdropped by a system listening on the same network. The technique is known as "packet-sniffing" and is a very effective method of collecting username and password pairs. This issue can be addressed through the use of network switching and the encouraged use of session encryption.
Network switches isolate individual hosts on a network, such that one host normally will not recieve any packets destined for another host, (in a regular Ethernet network, hosts receive all packets, but only listen for those that are destined for themselves). This sort of network infrastructure makes packet sniffing ineffective. Session encryption also renders packet sniffing ineffective by encrypting communications between the server host and the clients. Username and password pairs no longer travel as plain text, keeping them from being collected off the network.
The next most common method of compromising passwords is through brute-force guessing of the passwords, commonly referred to as "password cracking". Generally this involves obtaining a copy of the system password file, then running a program to check combinations and sequences of characters in an attempt to guess passwords, and compare their one-way encryptions to those in the copy of the system password file. To counteract this approach, systems now use what is known as a "shadow password file" where the actual encrypted passwords are stored in a separate, protected file, rather than in the system password file, (where account information is also kept, rendering it necessary to keep that file readable to all users on the system).
Another approach used on many Unix systems to combat password cracking is to "pre-crack" the passwords, at the time a user is selecting their password. This reduces the likelihood that passwords can easily be guessed through the use of password cracking software.
What remains is the possibility of brute-force guessing of passwords through repeated connections to a password-protected service, such as telnet. Through the careful use of Tcp Wrappers configuration to permit connections to a host only from hosts and networks where authorized users are expected to connect from, the likelihood that such an attack would succeed is substantially reduced. In order to succeed, such an attack would need to be launched from one of the hosts authorized to connect, and would be clearly identified in the system connection logs. (Note that the sysadmin should arrange to review system logs at least daily. This is best handled through a PERL script, such as authstats which emails a summary of all network connections accepted and denied by Tcp Wrappers.)
Regarding the strength of passwords themselves, there is an ongoing discussion among computer security professionals as to how to ensure that passwords are secure. A strong argument can be made for requiring users to change their passwords frequently in order to ensure that only limited damage can be done should one be compromised. The arguments going the other way are generally stronger.
If users are frequently required to change their passwords, they're more likely to pick simple passwords that are trivial to guess using brute-force methods. Given that good password changing programs pre-crack the passwords, ensuring that users cannot use trivial-to-guess passwords, and do not permit the use of a new password that closely resembles that from which it is being changed, the likelihood that users would resort to writing their passwords down, in a conspicuous location becomes very significant. It takes very little computing power to compromise a password that has been written down and taped to a computer monitor.
For this reason, it is best not to require users to change their passwords at intervals. Users should be instructed on how to select easy-to-remember, yet difficult to guess passwords, and the password changing program should ensure that passwords conform to accepted guidelines for strong passwords. It may be argued that requiring a longer minimum length of password would be beneficial, but in practice that would not likely add any benefit. Rather, it may result in users using simple patterns to pad the length of their password without actually increasing the password strength.
It should also be mentioned that an intruder who has compromised a password is very likely to use it shortly after compromising it. By the time the forced password change is due, if any account has been compromised, damage has very likely already been done. Required password changes are generally not an effective means of keeping unauthorized users off a computer system.
It is very important to avoid providing a false sense of security. Computer systems and the accounts residing on them do not suddenly become secure because users are required to change passwords often, are imposed a minimum length on passwords, or are locked out after a number of failed login attempts. Passwords are an inherently weak form of user authentication, but if they're carefully guarded they can remain effective.
Corrections to this document, suggestions on how I might improve it, or suggestions for other helpful documents should be sent via email to syl@alcor.concordia.ca