There are two common freely available systems that allow you to avoid sending reusable passwords over the Internet. These are Kerberos and the authentication server portion of the TIS FWTK . The number of commercial authentication solutions is growing as well.
Kerberos was developed at MIT by Project Athena (the same folks who developed the X Window System). It is designed to provide authentication and encryption services through modified versions of standard clients and servers, e.g., Telnet clients and servers.
Kerberos provides strong authentication in a distributed environment, and it is widely available. Some vendors provide Kerberos support with their operating systems; MIT has freely available implementations for many versions of UNIX ; and the code is freely available if you wish it to port it to an operating system that does not yet have an implementation.
Kerberos isn't an ideal solution, though. There are three major problems with it:
Kerberos shows great promise for the future, particularly if more sites adopt the Distributed Computing Environment ( DCE ), which uses Kerberos as the basis of its security. It could very well become the de facto standard mechanism for authentication on the Internet sometime in the next decade or so. In order for that to happen, though, it will need wider support from developers and vendors, and easier setup and maintenance. Meanwhile, it will probably only be used within individual sites.
Right now, most sites don't have Kerberos clients available, so even if you install Kerberos versions of your servers, your users will not be able to log in from arbitrary other sites, because it requires modified software on both ends.
The authentication server in the TIS FWTK is another commonly used solution for authenticating users coming in from the Internet. The server implements a variety of authentication mechanisms, such as standard reusable passwords (not recommended), S/Key, Security Dynamics Secur ID cards, and Digital Pathways SNK -004 cards. In addition, the server is modular and extensible, and is designed so that new authentication mechanisms can easily be integrated.
Traditionally, programs wishing to authenticate a user (such as the login program, or the ftpd daemon) have had to know how to authenticate a user; they have had to understand and implement whatever authentication method or methods were to be used. In a UNIX system, this means that these programs have to do all of the following to authenticate a user:
If you want to add a second authentication mechanism (for example, the S/Key mechanism, which we discussed earlier), you have to modify all of these programs to understand this second mechanism as well as, or instead of, the standard UNIX password mechanism. And if you later want to add a third authentication mechanism (for example, support for the SecurID cards), you have to modify the programs yet again; and so it would go for each additional authentication mechanism. Each time you modify these programs, you're making them bigger and more complex, and increasing the chances that you've introduced some kind of bug that's going to result in a security problem. (This is a serious risk because these are very security-critical programs - they control access to your system.)
The TIS FWTK authentication server takes a different approach. With it, you modify all the authenticating programs (e.g., login , ftpd ) once, to make them talk to the authentication server instead of doing the authentication themselves. All of the details of the authentication mechanism - e.g., what to prompt the user with, how to validate the user's response, etc. - are then handled by the authentication server. When you want to add or modify authentication methods, you do so by changing the authentication server (which is modular and designed to accommodate such changes), not by changing the individual authenticating programs.
A single authentication server can handle any number of client machines and programs, and any number of different authentication methods; different users within the same server can use different authentication methods. For example, some might use S/Key while some might use the Digital Pathways SNK -004 cards.
When a client program (such as login , or ftpd ) wishes to authenticate someone using the TIS FWTK authentication server, it has to go through the following steps:
This whole process is carried out with a single TCP connection between the client and the authentication server, so that the server knows it's talking to the same client and the client knows it's talking to the same server throughout the authentication process.
The authentication server consults its databases to determine how to authenticate that user and determines the appropriate prompt for the authentication mechanism for that user. For example:
Figure 10.3 shows how the TIS FWTK authentication server works.
The TIS FWTK includes a number of programs (such as ftpd ) that, in addition to other modifications and enhancements for security, have already been modified to use the authentication server. Converting an existing program to use the authentication server, rather than traditional UNIX passwords, is pretty straightforward. It typically involves only 20 or so lines of C code, examples of which are given in the toolkit.
The toolkit also includes some programs to support binary-only systems where you don't have the source to modify. For example, for systems in which you don't have the source code to the login program available for modification, the toolkit includes a program you can use as the user's shell (which is specified for each user in the /etc/passwd file) instead of one of the normal shells (e.g., /bin/csh or /bin/sh ) This replacement shell authenticates the user with the authentication server, and, if the user passes, starts his real shell.
The major problem in running an authentication server is getting secure communication between the client and the server. An attacker who can convincingly pretend to be the authentication server can authenticate as anybody.
Some configurations may have additional problems; for example, using shell replacement can produce problems, because not all programs deal well with situations in which a user's shell environment variable and the entry for that user in the /etc/passwd file do not match.
Many commercial systems offering to do authentication are now on the market. In particular, "single sign-on" systems are a hot topic right now. These are systems that supposedly let a user log in once (presumably once each day), and then automatically log the user in to whatever other systems that user needs to access, without the user having to log in to each system individually.
There are a variety of issues you need to think about when you are considering a commercial solution; the primary considerations are availability, security, and cost.
The only commercial authentication system that is used extensively on the Internet is the Secur ID system from Security Dynamics discussed earlier. A variety of commercial products, particularly terminal servers, support the system.