[Twisted-Python] Password hash for Perspective Brokers
spalax at gresille.org
Thu Aug 2 06:36:42 EDT 2012
On 27/07/2012 00:07, Flint wrote:
> 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.
I read and improved the patch you submitted .
Also, to answer to Jean-Paul about a salt already being used in the
authentication , I would like to stress that the authentication
method uses two hash methods, which for no reason should be the same
(they can be, but they do not have to).
* The first one (password hash) is the hash method used to store the
password (e.g. crypt(3) for the unix shadow password). It may or may not
* The second one (challenge hash) is the hash used during the
challenge/response part of authentication. It is salted, the salt being
a randomly generated string (the challenge).
Right now, password hash is either plain (no hash) or md5, without salt,
and challenge hash is md5, with the challenge as a salt. With the patch
I am submitting, password hash and challenge hash can be any method, the
challenge salt still is a randomly generated string, and the password
salt is anything you want, given that it can be computed given the
username and hashed password.
I drew a sequence diagram in the bug report , which can help to
undersand this part
> 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 at gmail.com <mailto:kevin.horn at gmail.com>>
> Subject: Re: [Twisted-Python] Password hash for Perspective Brokers
> To: Twisted general discussion <twisted-python at twistedmatrix.com
> <mailto:twisted-python at twistedmatrix.com>>
> <CA+U=zK3W21_BAg9fbLZzsAmRJXReHsvGmRYb0JLT4sgVV78R7A at mail.gmail.com
> <mailto:zK3W21_BAg9fbLZzsAmRJXReHsvGmRYb0JLT4sgVV78R7A at mail.gmail.com>>
> Content-Type: text/plain; charset="iso-8859-1"
> On Thu, Jul 26, 2012 at 11:43 AM, <exarkun at twistedmatrix.com
> <mailto:exarkun at twistedmatrix.com>> wrote:
> > On 02:28 pm, spalax at gresille.org <mailto: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
> > >authentication with perspective brokers is using MD5 . 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 , and I
> > >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 
> > >to use (or not) a salt, and a different hash function. I am not
> > >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
> > >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...
> Twisted-Python mailing list
> Twisted-Python at twistedmatrix.com
More information about the Twisted-Python