Problem - Kevin Tafuro

Clearly, choosing the right technology requires a thorough analysis of requirements
for an authentication system. In this chapter, we’ll look at several common requirements,
then examine common technologies in light of those requirements.
However, let us first point out that it is good to build software in such a way that
authentication is implemented as a framework, where the exact requirements can be
determined by an operational administrator instead of a programmer. PAM (Pluggable
Authentication Modules) lets you do just that, at least on the server side, in a client-server
system. SASL(Simple Authentication and Security Layer) is another such
technology that tries to push the abstraction that provides plugability off the server
and into the network. We find SASLa large mess and therefore do not cover it here.
PAM is covered in Recipe 8.12.
There are several common and important requirements for authentication mechanisms.
Some of these may be more or less important to you in your particular environment:
Practicality of deployment
This is the reason that password systems are so common even though there are
so many problems with them. Biometrics and physical tokens both require physical
hardware and cost money. When deploying Internet-enabled software, it is
generally highly inconvenient to force users to adopt one of these solutions.
Usability
Usability is a very important consideration. Unfortunately, usability often trades
off against good security. Passwords are a good example: more secure mechanism
would require public keys to establish identity. Often, the user’s private
key will be password-protected for defense in depth, but that only protects
against local attacks where an attacker might get access to steal the key—a welldesigned
public key–based protocol should not be vulnerable to passwordguessing
attacks.
Another common usability-related requirement is that the user should not have
to bring any special bits with him to a computer to be able to log in. That is,
many people want a user to be able to sit down at an arbitrary computer and be
able to authenticate with data in his head (e.g., a password), even if it means
weaker security. For others, it is not unreasonable to ask users to carry a public
key around.
When passwords are used, there are many different mechanisms to improve
security, but most of them decrease usability. You can, for example, expire passwords,
but users hate that. Alternatively, you can enforce passwords that seem
to have sufficient entropy in them (e.g., by checking against a dictionary of
words), but again, users will often get upset with the system. In many cases, adding
something like a public key mechanism adds more security and is less burdensome
than such hacks turn out to be.
364 | Chapter 8: Authentication and Key Exchange
This is the Title of the Book, eMatter Edition
Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.