<snip>If you're paranoid, place the authentication mechanism on a machine that sits behind some level of network security, and don't let the passwords pass the wire into unsafe networks at all. Have the webserver call out to this authentication system passing a strong token that can be used to authenticate, and have the auth. system pass back a yes/no.
Putting words in your mouth: I agree. Digest auth really isn't much more security than basic auth. If you must, pass the password in plain-text using Basic auth and protect the transport layer using SSL. Once authenticated, give the user a strong authentication token to send back with future transactions, then send the user back to a non-SSL transport layer for speed/performance reasons.
The ability to have the plaintext passwords stored in some "more secure" repository on the server side is covered in Digest by the the ability of the HTTP server to retrieve H(A1) from some other source (RFC2069, sec. 2.2).
The Basic/SSL -> "strong authentication token" mechanism you describe is open to both replay and MITM attacks. To avoid replay you would need to timeout and renegotiate the tokens (which is provided with Digest's nonce management). To avoid MITM the token would also need to be somehow tied to the request URI and body (impossible with cookies, provided in Digest auth).
Cryptographically, the correct solution is SSL/TLS. However, in practice we're not going to be running every single authenticated connection over SSL any time soon. As far as I can tell Digest is a step in the right direction, has already been specified, and securely* solves the problem it claims to solve (unencrypted passwords on the wire), which in my opinion puts it ahead of any ad-hoc homegrown solution to the same problem.
Russell
* I haven't seen any reports of weaknesses in Digest's design, and I'm keen to be informed if I'm wrong on this.
-- AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
