[ZODB-Dev] CHAP with ZEO

[Jeremy Hylton]

>>>>> "MP" == Michel Pelletier <michel@digicool.com> writes:

  MP> I'll have to read the RFC more closely.  Do you know of any
  MP> pre-existing digest auth python modules, perhaps from the work
  MP> done on Grail?

There's client-side support in urllib2.

  >> CHAP requires that the secret be available in plaintext
  >> form. Irreversably encrypted password databases commonly
  >> available cannot be used.

  MP> I don't see how digest auth beats this limitation. 

I didn't mean to suggest that it did.  The HTTP digest RFC goes out of
its way to explain the many problems of digest-style authentication.

  >> The HTTP digest authentication mechanism (RFC 2069) is a
  >> variation on the same theme, but seems to be designed more
  >> carefully.  Certainly, the operational environment for PPP
  >> servers is different than it is for HTTP servers.  A ZEO
  >> environment is more like HTTP than PPP.

  MP> Really?  I don't agree.

  MP> There isn't really anything PPP specific about CHAP, I imagine
  MP> it could be implemented over any protocol, simple, well-defined
  MP> shared-secret challenges and responses.

The operating environments are different.  A PPP server has far fewer
users than an HTTP server.  They perform different kinds of
interactions.

That said, the HTTP digest mechanism has, for example, a discussion of
the man-in-the-middle attacks that CHAP is vulnerable to and some
means to limit the vulnerability by choosing a challenge with some
information about who is being challenged.  I didn't see any of that
in CHAP.

Note that the CHAP protocol says that you should periodically
re-authentication the other side.  The HTTP digest mechanism does it
per request.  One or the other makes some sense.

  >> As Andrew said in an earlier message, we do a disservice to the
  >> community if we promote a system with a security infrastructure
  >> that we know is substandard.

  MP> CHAP is sub-standard weak authentication?

There is no question here.  People have been using Kerberos since the
last millenium :-).  For the kind of environment that Toby described,
it seems like a good solution.

Jeremy