It's easy to agree with Steve that passwords-in-the-clear are
unacceptable, and still believe that there are cases where
shared-secret authentication is all you need (presumably because you
don't want to pay either the license fees, complexity or computer time
for some public key based authentication scheme).
There are many problem with password schemes, but the worst ones are, I think:
1. Both parties will be tempted to send the password over the net
in the clear.
2. Both parties will be tempted to store the password in the clear.
3. Its a pain to set-up the password between the parties the first
time.
4. Its a pain to remember the password (manage all one's passwords).
5. Its tempting to use bad (guessable) passwords.
These problems interact somewhat (the better the passwords you use, the
more likely you need to store them on paper). And since passwords
authenticate the message channel, rather than the messages themselves,
password authentication is weak in a fundamental sense. Someday, we'll
all be using public key based schemes -- after 2000 for sure :-).
On the other hand, passwords are familiar, simple and better than
nothing (modulo a "false security" problem). Most of the problems
enumerated above are tough, but on today's Internet, problem #1 is
special, and it can be addressed pretty easily.
The next revision of the Secure HTTP specification provides a
shared-secret authentication scheme which:
1. Never sends passwords over the net in the clear.
2. Prevents splicing attacks (guarantees message integrity).
3. Doesn't use patented techniques (as best I can determine).
4. Doesn't use cryptography (freely exportable).
5. Provides protection against replay attacks.
6. Is reasonably simple.
The message being authenticated is preceeded by a message digest header
as follows:
MAC-Info: <hash-alg>,<key-id>,<timecode>,<hash-value>
where:
timecode is seconds since the epoch (unsigned 32-bit in hex)
key-id can be considered the "account name"
hash-alg e.g., "RSA-MD5", "NIST-SHS"
hash-value is hash(shared-key || timecode || message) in hex
Use of the timecode by the communicating parties to deter replay
attacks is at their discretion.
-Allan