[Twisted-Python] Re: Questions about the Perspective Broker login mechanism

[Julien Peeters]

On Mon, 2007-08-20 at 12:47 -0400, David Bolen wrote:
> Julien Peeters <jj.peeters at gmail.com> writes:
> 
> > For the moment, except I make a mistake, only credentials which
> > implements IUsernamePassword are supported by the PBClientFactory.login
> > method. Then if, for instance, passwords are stored with a SHA hash
> > method, I can't use it as it is. 
> 
> Ah, I see - sorry I missed that.  Yup, so I agree you may want to
> override that portion of PBClientFactory (and perhaps the matching
> remote_login in PBServerFactory) in your own mechanism as well.
> 
> It's possible the existing signature might still work even with a
> hashed password, since the password field from the supplied
> credentials are passed unchanged to the challenge response generation
> function, with nothing other than the client/server shared
> challenge/response implementation caring that it is clear text, but
> that does sort of "bend" the interface for IUsernamePassword so it's
> probably clearer to implement your own.

Yes, It's what I noticed. When you use a username/password strategy it's
all right. With a precision that the password have to be hashed with the
same method with which the stored password at the ckercker side is
hashed. 

In the case of other type of credentials, it's not so trivial.

> > (...)
> > May be it's possible to put a kind of "credential remote reference" at
> > the server side which serve as a proxy for the real credential. 
> > Form a security point of view it's all right because remote reference
> > does not transmit data but juste provide remote method calls.
> 
> Not sure this is a big win, since at some point in time you need to
> transfer over the actual credentials used for authentication anyway.
> So it's really a tradeoff between an established remote object method
> interface (to retrieve the credentials) or the type of credential
> object transmitted in general when sent as copyable data.  Toss up,
> but you're free to try either approach.

And so. I noticed that the solution I proposed does not correctly work
because the "proxy" have to implements the interface the checker match
for. And it's impossible to do cleanly.

> > And then, instead of give the _PortalAuthChallenger to the portal as the
> > credentials, that proxy would be given. The proxy have to implement the
> > same ICredentials interface to be compatible with the checker. And it
> > have also to implement a "zero-knowledge password proof" mechanism
> > (response/challenge) to communicate with the real credentials to
> > preserve security. 
> >
> > This solution is based on the existing one. And may be would be more
> > flexible? Why not a starting point for an effective solution?
> 
> Why not indeed?  If I were you and I had convinced myself the
> authentication approach was worth replacing in my application (per my
> last response) at this point I'd just go ahead and do some
> implementation to see how it goes.  You can certainly achieve
> everything you're talking about by just overriding some of the
> existing default behavior.

In theory all is possible. But it's an other challenge that to find a
good and clean way to do it :-).

I interested in all propositions if someone have any ideas.

Julien.