[JDEV] Re: Account information storage, plaintext? ...AND JabberD password storage

[Richard Dobson]

> 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