Hi, i've faced the same problem and submitted a patch a few month ago, your can check it here http://twistedmatrix.com/trac/ticket/4398 you'll find also a complet example attached. My first problem was that, the way twisted pb authentication works we're supposed to have a plan version of passwords at server side. Or this is not always the case, most application store a hashed version of the password, the hash method may be different from the one twisted pb use to pass the credential over the network and thus, we're not able to compare those values. In my solution the user can define a custom hash method and tell twisted to use it, so that the password given by twisted over the network will be hashed the same way that the application does before storing it (in database for example), which means we can check if the password is correct without having a plain version of it. Not that, If we don't "customize" the hash method, the original twisted behaviour in used instead, and thus compatibility is preserved. -- G Message: 1
Date: Thu, 26 Jul 2012 12:36:57 -0500 From: Kevin Horn <kevin.horn@gmail.com> Subject: Re: [Twisted-Python] Password hash for Perspective Brokers To: Twisted general discussion <twisted-python@twistedmatrix.com> Message-ID: <CA+U= zK3W21_BAg9fbLZzsAmRJXReHsvGmRYb0JLT4sgVV78R7A@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1"
On Thu, Jul 26, 2012 at 11:43 AM, <exarkun@twistedmatrix.com> wrote:
On 02:28 pm, spalax@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