> In fact, I do not like sysadmins (myself included) knowing users' > passwords on the systems _I_ manage. But that's drifting off-topic, so > let's hold that thought for a minute.
Thats personal preference really and is upto the admin concerned, if an admin does not want to be able to see the passwords there are ways. > The next question along this line might be: where does the > implementation of such a feature, should it be desired, lie? Does it > require a change in any way to Jabber/XMPP that requires the 'designers' > of the protocol? Nope not really to do with the protocol per se. > If not, does it lie with the JabberD team? (Remember, > Rob Norris is the guy writing JabberD2, so BE NICE! :-) ) Or does it > lie with the transport writers? Both, if you are doing reversable encryption (which is the only way it can work ATM AFAIK) > When you know the answer to this > question, politely ask those responsible if there might be a way to have > such a feature. Or, as always with open source, grab some code and go > crazy. :-) Go ahead and add feature requests :) > Might I suggest one possibility? Again, for those reading this, please > note Rob Norris is "the man" with regards to JabberD2 development, so be > nice. Would it be possible, Rob, to offer the option to the JabberD > admin to store passwords using, say, MD5 hashes? Passwords would still > come from clients as they do now. The only change required is how > JabberD stores them and, if it's configured to use MD5, how it does the > comparison; i.e., > > (plaintext_sent = plaintext_stored) > vs. > (MD5(plaintext_sent) = hash_stored) Nope currently not possible (as already discussed), the only option is reversable encryption, the original plaintext password is required for the current authentication mechanisms to operate, read Matthias explaination. > As for the original transport question, reversible encryption might be > an option (though again, not sure who needs to be buttered up in that > regard). The only real option see above. > Personally, I would love to see NO 3rd party passwords stored on the > server, but rather have the Jabber client send any 3rd party passwords > whenever the client connects (this way the USER is responsible at the > client side for securing that information, and jabber admins don't have > culpability for compromises passwords of systems they do not manage). > However, I understand that would require a fundamental change in the way > Jabber works, if only because the user would be required to re-enter all > that 3rd party information from EACH client PC they used, as opposed to > having the Jabber server store it for them (a la rosters, etc.). Yup creating a mechanism for the client handling auth is a possibility that ive been thinking about, but it does require protocol additions, changes to transports and all clients accessing them, so unless their is a major push by a large number of people then I dont see it happening. Richard _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
