[ZODB-Dev] RFC: Proposal for AuthZEO (was SecureZEO one day)

[Christian Reis]

On Thu, Jan 16, 2003 at 11:40:24AM +0000, Toby Dickenson wrote:
> On Wednesday 15 January 2003 9:35 pm, Christian Reis wrote:
> 
> > Three new classes are introduced: AuthStorageServer, AuthZEOStorage
> > and AuthClientStorage. These classes inherit from StorageServer,
> > ZEOStorage and ClientStorage respectively.
> 
> Why not put the new functions into StorageServer, ZEOStorage and 
> ClientStorage?

Well, it depends on what sort of function we are talking about. Any
change should be backwards-compatible (right?) so we have the option of
either:

    - Adding an API that provides something like enable_auth() 
    - Adding optional parameters to the constructor (something like 
      auth_file  or auth_hash?)

I don't like any of these approaches very much (I have to work on a GTK+
wrapper that does enable_* and it's just ugly, and I think the
__init__() API is already fat enough as it is, weighing in at 7
parameters for StorageServer and a whopping 14 for ClientStorage).

Am I missing something obvious?

> > 4. Protocol
> 
> The protocol autenticates clients to the server. Is there value in making this 
> symetric, so that clients know they are talking to an authentic server?

Since I wrote this, I remembered Jeremy had suggested looking into SRP.

Well, Tom Hollyrod has implemented SRP in pure python in his SRPSocket
[1] package. I've looked at it and the code looks very nice, and quite
usable by us. I've asked him if he would allow us including parts of it
with ZEO and he had no problem with the ZPL (which I sent attached to
him).

SRP gets us some extra points that my basic protocol doesn't - it stores
passwords on the server in ciphertext and it protects is from
man-in-the-middle attacks, which mine doesn't. Since it's already
implemented, I'm inclined to use it.

Anybody against it? The only drawback seems that it's a bit slow (0.400s
for client and around that for the server on my 1Ghz box), but Johan has
said it's an easy hack as a C module and besides Tom offers C code [2]
that does it already.

> >        but it seems the sha and md5
> 
> md5 isnt really wide enough for this. It would probably be sufficient, but 
> there is no reason to avoid sha.

Specially given that sha is included in Python2.1 standard. SRP uses
sha.new() internally.

> > 5. Notes and Issues (RFC)
> 
> Where will it get the random challenge from?

The server? I was assuming it would generate the challenge using the
PRNG available on-box; SRP does so, (random.randing()) at least.

Take care,
--
Christian Reis, Senior Engineer, Async Open Source, Brazil.
http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL