Following from the How to enforce password complexity on a Hash? post, here are some more thoughts on the use of a hash as password.
The key issue is that without SSL, there is no way we can really protect the user against somebody who is listening in (remember that the session ID is as good as a password).
In terms of the hash being the password (as it is with TeamMentor), if the hash is discovered, then it is as good as a password (although not usable via the GUI).
I quite like fact that the server never knows the password (it only knows the hash, which is the password salted with the username). Also note that on the server-side the hashes are stored by default in an XML file, since in a normal install there is no server-side-secure-storage capabilities.
The only attack I can see we might be able to mitigate is the reuse of stolen hashes. I.e. we could hash the current hash with the current sessionID on login, which would make it a 'only valid during this session token' which in a way is probably as secure as we can get. Note that if the attacker is able to grab the hash via traffic sniffing, then he can also grab the session ID (which for that session is as good as a hash).
If we go down this route (hash+sesssionId), there is still going to be one moment when the username+password hash will need to be sent to the server (the one with no sessionId salt). That moment is when an account is created (the server needs to have a 'clean hash' to compare with the hash+sessionID hash :) )
At the moment, TeamMentor's most secure login solution is the Windows/AD integration which TeamMentor fully supports since 3.1.
Another option, is adding OAuth support (it would be great to be able to use Twitter, Google or Facebook as an identity provider)
Note: On the topic of the multiple type of hashes, see this answer in the OWASP Security 101 list by Michael Coates
Note: On the topic of the multiple type of hashes, see this answer in the OWASP Security 101 list by Michael Coates
