[ZODB-Dev] ZEO signal feature

Christian Reis kiko@async.com.br
Wed, 25 Sep 2002 11:11:42 -0300


On Tue, Sep 24, 2002 at 08:16:23AM +0100, Toby Dickenson wrote:
> On Monday 23 Sep 2002 7:30 pm, Christian Reis wrote:
> 
> > We have been working on something very simple for now - passing a
> > username/password pair over RPC when initializing ClientStorage, and
> > having the server authenticate that U/P and, if invalid, raise an
> > authentication exception. The password is crypted to difficult things
> > for evil packet sniffers, but proper protocol security is easily
> > implemented by connecting to ZEO through stunnel.
> 
> I can see what advantage using crypt on the password is giving you here.

You *can't*, I surmise. :)

> If using stunnel then you need to be able to trust that:
> 1. It is really stunnel, not an attacker, listening on the local stunnel port
> 2. It is really ZEO, not an attacker, listening on the remote port
> 3. Your operating systems, stunnel, and ZEO have not been compromised.

If your machines haven't been root-hacked, these are reasonable
expectations. The client stunnel/OS are of course danger points, since
they can only be protected with physical security. Do you have a
suggestion to help this? This risk exists with any security mechanism,
I'm pretty sure.

> If not using stunnel, isnt your scheme vulnerable to replay attacks? Sure, an 
> attacker dont know what the password is. As long as he knows the crypted 
> passed then he can still connect.

Yes, it is. It's merely obscuring it, like CVS does, and now I'm going
to get the "security through obscurity" preach, aren't I? :-) Yes, a
simple CHAP can be easily implemented, as soon as this is working in
basic, we'll turn to using it, since a simple crypt it dumb.

> (or, I may be reading all the wrong details into your one sentence protocol 
> description. Is so, I appologise)

No, pretty accurate.

> I think either of two levels make sense:
> a. Send plaintext username and password. At least it doesnt give a false sense
>    of security.
> b. Implement something like CHAP to avoid the replay attack.

Yep. crypt() was just a teaser, and we're on a trusted network anyway. 

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