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

[David Bolen]

Julien Peeters <jj.peeters at gmail.com> writes:

>> Why you'd bother (when challenge/response is implemented for free) is
>> another question, but it's certainly possible.  I suppose if you're
>> using an SSL link for the PB connection with appropriate certificates
>> you could consider the challenge/response an extra round trip, but
>> it's got to be pretty insignificant compared to the overall session.
>> 
>> -- David
>
> I don't especially use/want a SSL link. But I would like to use
> different hash methods than md5 based ones. For instance, I'll possibly
> need SHA or MD5CRYPT (I don't know if it's compatible with md5) hash
> methods. Or why not any other one...

Of course you're certainly allowed to prefer something else, although
you might want to consider if the effort is worth it.  MD5CRYPT is
just an MD5 version of the classic Unix crypt() approach, including
salt, so isn't compatible with a direct MD5 hash.  But the PB approach
already has the random challenge as a salt, so MD5CRYPT shouldn't be
any more robust than the current approach - probably slightly less so
since it doesn't have the double hash of the password.  But it would
be compatible with Unix systems using MD5CRYPT for their passwd
entries if you were trying to compare directly to local entries.

If you're avoiding MD5 simply because it's been shown to no longer be
cryptographically secure (collisions can be generated for a given
hash), it's still worth considering what impact that really has on
this mechanism's use of MD5.  

While I'm not a cryptology expert (and I suspect analyzing such
vulnerabilities is often distinctly non-intuitive), with respect to
passwords, I believe the biggest exposure with MD5 is those systems
that store a direct MD5 hash of a password that an intruder can obtain
and then attempt attacks on by trying to produce alternate passwords
that will hash to the same value (and in some approaches, backtrack to
the true original password).  I'm not sure that sort of attack would
practically be launched against PB.  In particular, salts help defend
against that sort of attack.

For a PB session, the most common attack would be an attacker
attempting to impersonating a client, in which case all they'll have
access to is the random challenge.  Without seeing an actual response,
they've no hash to try to duplicate, and I'm not sure that the MD5
vulnerability comes into play at all.

If you're concerned about attackers with physical access to your
network and/or packet flow, things get messier.  If the attacker is
using a man-in-the-middle attack, I'm not sure they'd even bother with
attacking the password - just let the challenge and response flow
through, and then observe the traffic, or hijack the session once
established without ever figuring out the password.

If they didn't want control of the session, but just wanted the
password for other purposes, they could sniff traffic, and obtain the
challenge and response (and obviously have access to the source code
available to see how they're combined), but would have to deal with
the response having a hash of a hash for the password component.  I
know it makes use of the MD5 vulnerability more difficult, but may not
prevent its use entirely.

To be honest though, if I were really concerned with the latter two
cases - traffic interception/sniffing - I'd go right for link level
security (SSL with certificate verification on both ends), since even
with any other hash why give an attacker access to any of the hash
information if not necessary.  And no authentication system will
protect against a man-in-the-middle attack hijacking a session once
established.

> Then, I would like to use different credentials and to the other side,
> different login method to be compatible with credentials I use.
> The actual implementation force to use md5 hash method. It's what I'm
> looking for to change if I find a good way to do what I habe in mind.

I'm not sure you need to change the login method signature, since it's
just passing an arbitrary credentials object which can be as complex
as you want.  But sure, you can make up your own checker interface to
match your particular credential information.  Similar to how PB
implements the IUsernameMD5Password checker to incorporate the MD5
operation.

So, feel free to have at it.  There are probably a few ways you could
take control, but I were doing it, I'd probably take my Portal
subclass and make it directly implement IPBRoot (thus avoiding the
registered adapter _PortalRoot).  Then use the existing classes
(_PortalWrapper, _PortalAuthChallenger) as a model and/or subclass
them, and build your own process from the IPBRoot rootObject() call.
You'd be in complete control and can do anything you'd like.

If you haven't already, you might just start out with using the
existing implementation since it'll be easy enough to replace out
later and you might find that there are other aspects of the system
that deserve attention before delving too deeply into the very initial
authentication.

-- David