RE: SHA Authentication

[Jon Parry-McCulloch <John.Parry-McCulloch@liffe.com>]

		You've got the right idea of how to create the hash.
However, when binding to
		the server, the password is sent in plaintext.  

	Um, this isn't making sense to me. The password is sent in plaintext
frm where? Not the client, surely.

		The server will base64-unencode the hash from the db,
retreive the salt from the hash, and use
		that salt to hash with the binding password.  Then it
compares the hashed
		binding password with the hashed password from the database.
If they're the
		same, you've authenticated yourself.

	The DB has a plain copy of the password, yes? And it hashes this
stored value with the received salt
	and compares it with the received hash. This is what I said (or
meant to say) in the first place.

		Now, if you're trying to compare the hashes using a client
that you've
		written, you'd have to grab the hashed password from the
server (assuming you
		have read rights to the userPassword attribute) and get the
salt from the
		attribute, but the server wouldn't be involved in the
compare since you could
		(and should) do the compare locally.  If you didn't have
read access to the
		attribute, there really isn't a way of checking the
password, since you
		wouldn't have access to the salt.  Did I make any sense? ;)

	Yeah, sorry. That was just me typing without thinking.

		> Now, am I wrong in assuming that OpenLDAP1.1.2 supports
only the SHA form
		> and not the SSHA form? If so, are there any plans to
include the SSHA form
		> soon?

		It's already in the development tree. (for at least the last
couple weeks
		now.)  Kurt, kick me if I'm wrong about this, but I think
SSHA and SMD5
		support is slated for release in v1.2.

	<groan> I really need SSHA, like, yesterday. I'd imagine that the
files affected are few, yes?

	Jon