We are only talking about protecting the login page, because it uses a permissions system that utilizes sessions. All the relevant variables are stored in the session which is managed by PHP. I caught the digest auth in the RFC, but didn't bring it up because it wasn't any different from my clients perspective than SSL. As my client is fond of saying. I know all IT is actually run by magic gerbils. As long as those magic gerbils keep running I'M Happy.
Sincerely, Steve -----Original Message----- From: Bart Whiteley <[EMAIL PROTECTED]> Sent: Sunday, March 16, 2008 7:49 PM To: Provo Linux Users Group Mailing List <[email protected]> Subject: Re: Hashing a hash == bad On Sun, Mar 16, 2008 at 11:14 AM, Steve Morrey < [EMAIL PROTECTED]> wrote: > > The reason is pretty simple. > Even if you hash the hash, you are still sending the authentication > token that the server cares about, in plain text across the internet. > This could allow for a replay attack. Nothing can prevent that except > for implementing SSL at least on the authentication page. Enabling SSL might be the easiest way to prevent a replay attack, but not the only way. Did you read RFC2617? > > Even if they only used a self signed SSL cert SSL with a self-signed certificate may protect against replay attacks, but is vulnerable to man-in-the-middle attacks. Get a real certificate. > and only used it on the > log in page, > Since HTTP is stateless, how is it sufficient to only protect the login page with SSL? /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */ /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
