Problem - Kevin Tafuro

so why bother building a secure channel? Similarly, you might already be able to
establish an authenticated remote connection to a server through something like SSL,
in which case you get a secure channel over which you can do a simpler authentication
protocol. (Mutual authentication versus one-sided authentication is therefore
another potentially interesting requirement.) Of course, that works only if the server
really is authenticated, which people often fail to do properly.
Whether or not you have a secure channel, you will probably want to make sure that
you avoid capture replay attacks. In addition, you should consider which possible
masquerading scenarios worry you. Obviously, it is bad if an arbitrary person can
masquerade as either the client or the server just from watching network traffic.
What if an attacker manages to break into a server, however? Should the attacker
then be able to masquerade as the user to that server? To other servers where the
user has the same credentials (e.g., the same password)?
In addition, when a user shares authentication credentials across multiple servers,
should he be able to distinguish those servers? Such a requirement can demand significant
trade-offs, because to meet it, you will need either a public key infrastructure
or some other secure secret that users need to carry around that authenticates
each server. If you are willing to assume that the server is not compromised at
account creation time but may be compromised at some later point, you can meet
the requirement more easily.
We have already mentioned no susceptibility to password guessing attacks as a possible
requirement. When that is too strict, there are other requirements we can
impose that are actually reasonable:
• When an attacker steals the authentication database on the server, an offline
cracking job should be incredibly difficult—with luck, infeasible, even if the
password being attacked is fairly predictable.
• Guessing attacks should be possible only by attempting to authenticate directly
with the server, and the login attempt should not reveal any information about
the actual password beyond whether or not the guess was correct.
• There should not be large windows of vulnerability where the server has the
password. That is, the server should need to see the password only at account
initialization time, or not at all. It should always be unacceptable for a server to
store the actual password.
No doubt there are other interesting requirements for password systems.
For authentication systems that also do key exchange, there are other interesting
requirements you should consider:
Recoverability from randomness problems
You might want to require that the system be able to recover if either the client
or the server has a bad source of randomness. That is generally done by using a
366 | Chapter 8: Authentication and Key Exchange
This is the Title of the Book, eMatter Edition
Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.