[Twisted-Python] Password hash for Perspective Brokers

Kevin Horn kevin.horn at gmail.com
Thu Jul 26 13:36:57 EDT 2012

On Thu, Jul 26, 2012 at 11:43 AM, <exarkun at twistedmatrix.com> wrote:

> On 02:28 pm, spalax at gresille.org wrote:
> >         Hello
> >         I have a problem with checkers in Twisted, which could be
> >solved by
> >adding a new feature. I think I can write the necessary code, but
> >before
> >doing so, I would like to hear you about it.
> >
> ># The problem
> >
> >         If I am right, the only way passwords can be hashed when using
> >authentication with perspective brokers is using MD5 [1]. However,
> >there
> >are two flaws with it.
> >
> >* First, MD5 is no longer considered sure. It may be possible, from the
> >hashed password, to find the original one.
> >* Second, in the current implementation of Twisted, no salt is used to
> >hash the password. A salt is considered good practise : it is harder to
> >find the password from the hashed form, and two identical passwords
> >have
> >different hashed form, which prevent someone looking at the hashed
> >passwords to see if two users have the same password.
> The second point is incorrect.  The hash is salted.  See the `respond`
> method in twisted/spread/pb.py.
> ># A solution
> >
> >         I tried to implement the solution proposed in [1], and I think
> >I can
> >manage to do it. However, this seems to be a not-so-smart hack, which
> >is
> >not guaranteed to work in future releases of Twisted. That is why I am
> >proposing a patch.
> >
> >         The patch would introduce some arguments to class
> >PBServerFactory [2]
> >to use (or not) a salt, and a different hash function. I am not settled
> >down yet about the new signature of this class, but what is sure is
> >that
> >the default must be the actual behaviour, not to break programs already
> >using Twisted. Then, I hesitate between
> A good approach would be to parameterize the supported authentication
> mechanisms in an extensible way, rather than just hard coding one or two
> new (probably better) options.
> In other words, a SASL implementation for PB would be the best way to
> go.
> The existing API and behavior should indeed be preserved as-is for
> backwards compatibility.  The new authentication features should be
> exposed under a new API - either as new optional arguments accepted by
> PBServerFactory (and perhaps PBClientFactory) and new login methods
> (again, probably on those two classes).
> Jean-Paul
It would probably also help if someone finished the "Generic SASL
implementation" ticket.

Lessee, who was working on that last?

Crap. It was me.

Sorry about that.

Kevin Horn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://twistedmatrix.com/pipermail/twisted-python/attachments/20120726/191265a5/attachment.htm 

More information about the Twisted-Python mailing list