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

[David Bolen]

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.

> (...)
> 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 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.

-- David