+1.  (See PaceAuthentication.)

Leigh L. Klotz, Jr. wrote on 2/22/2006, 1:53 PM:

 >
 > I agree.  HTTPS+Basic is better than Digest Authentication, which is
 > fatally
 > flawed.
 >
 > Section 4.11 of RFC2617 addresses this issue, but not in plain terms, so
 > many have overlooked it.
 >
 > RFC2617 section 4.13 says "First the password file must be protected
 > as if
 > it contained unencrypted passwords, because for the purpose of accessing
 > documents in its realm, it effectively does."
 >
 > Here's what that means:
 >
 > In order to perform digest authentication, the server must store one
 > of the
 > following
 > (A) The plaintext password
 > (B) A hash of the plaintext password
 >
 > Most sensible developers would choose (B), because (A) is obviously
 > bad, and
 > everybody already stores some kind of hash of the password.
 >
 > Unfortunately, with the digest auth algorithm, knowing the hash of the
 > password is good enough to log you in through a programmatic client.  You
 > can't find out the actual password you could type at a web browser,
 > but it's
 > trivial to use a program to make use of the known hash.
 >
 > Therefore, with digest authentication, the server has to store a string
 > that, if it got out, could be used to log you in.
 > In my book, that's about as bad as storing the plaintext password.
 >
 > Leigh L. Klotz, Jr.
 > Xerox Corporation
 >
 > -----Original Message-----
 > From: [EMAIL PROTECTED]
 > [mailto:[EMAIL PROTECTED] On Behalf Of James M Snell
 > Sent: Tuesday, February 14, 2006 11:59 AM
 > To: atom-protocol
 > Subject: HTTP authentication
 >
 >
 > Our implementation of APP currently uses HTTP Basic authentication
 > over an
 > SSL connection.  The spec calls for "HTTP Digest Authentication and/or
 > CGI
 > Authentication" and includes a comment "[rfc.comment.4:
 > expand on HTTP basic and digest authentication, or refer.]"
 >
 > With our implementation(s), we would like to be able to use as broad a
 > spectrum of authentication mechanisms as possible -- without being
 > limited
 > to just one or two mechanisms.  The choice should be up to the
 > application.
 >
 > So what's the story here?  We obviously need to complete this section.
 > I'm not a security expert and typically just end up sounding silly when I
 > try to write up anything remotely related to security so it would be
 > great
 > if someone could write up a pace that fills in the security section.
 >
 > - James
 >

-- 
John Panzer
Sr. Technical Manager
http://journals.aol.com/panzerjohn/abstractioneer


Reply via email to