____________________________________________________________ 3rd PARTY ACCOUNT INFORMATION STORED IN PLAINTEXT
Jamin W. Collins wrote:
followed by "He said"..."She said"...Does anyone else see it as a concern that the Jabber server (1.4.2 release) and popular transports (aim-t, jit, msn-t, and yahoo-t) save user account information (user name and password) in plaintext for anyone with read access on the Jabber server to see?
All I can think is Luke Skywalker's wing commander in the original 'Star Wars' movie..."Stay on target"... :-)
I may be wrong, but this thread is slowly drifting towards another discussion on security, and if we're not careful, it will end up being another flame war and the original question and the point it was seeking will be lost.
Jamin simply asked a question asking if anyone was concerned, specifically regarding the storage of username/password combos to OTHER systems like AIM, MSN, etc.
Yes, Jamin, I am concerned. I do not feel a sysadmin (one of many hats I wear) should have information about a users' usernames/passwords on remote systems, WHENEVER POSSIBLE. <==NOTE THIS BEFORE RESPONDING. Why should I know what my users' AIM/ICQ/MSN/Yahoo! account names and passwords are? Do I have the right to know my users' bank account numbers? Their ATM PINs? I think not.
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.
As already voiced in this thread, the reasons for storing 3rd party usernames/passwords is due to the needs of transports to have that information in order to properly 'impersonate' a user on that 3rd party system. But what is really meant is that the transports need to KNOW the actual usernames/passwords in order to plug those in when a user connects to said 3rd party system.
As suggested, possibilities exist for doing reversible encryption/hashing so that said transports can, in fact, have access to actual usernames/passwords while at the same time protecting such information through basic obfuscation. (ooooh, BIG word)
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? 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? 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. :-)
____________________________________________________________ JABBERD PASSWORD STORAGE
Now, returning to the drifting topic of sysadmins knowing passwords on their own systems, I would like to ask if anyone is concerned that JabberD itself stores ITS users' passwords in plaintext, because I for one AM. I understand the argument that services like jabberd/apache/whatnot should be configured to run as a given user and only THAT user should have access to the files, so why do we need to encrypt/hash them?
Well, let me ask a few questions:
1. How does *nix (pick your flavor) store users' passwords? 2. How does Windows NT/2K/XP store users' passwords? 3. How does Apache store users' passwords?
Not ONE uses plaintext passwords, at least by default. (Not even sure if you could, but that's another topic again). *nix typically uses some form of encryption, if not outright subverting things more by using yppasswords, NISpasswords, etc. Windows NT/2K/XP same thing. Even Apache uses either DES crypt or MD5 hashes.
And speaking of Apache, that's probably a good comparison to use. Apache offers things like basic HTTP authentication, which requires the user to send plaintext passwords across the wire, where Apache then does its hash and compares the hash against its stored password. If as a webserver admin you fear plaintext passwords on the wire, you use SSL.
Regarding Jabber/XMPP, the same holds true. Rob, you mentioned in one post "Well, I think that plaintext passwords on the wire are more of an issue than plaintext passwords in the data store." I'm afraid I have to side with Michael Brown's response. Plaintext passwords on the wire are not as much of an issue as stored passwords on a system. Michael Brown covers the points well.
And in the case of JabberD, it too has clients sending passwords in plaintext, but that's ok, if only because you can subvert that by using SSL-only connections to the Jabber server. And SSL is built into JabberD, so it's not like it's an add-on or something only a few people have. However, the storage of passwords ON the Jabber server is still a concern.
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)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).
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.).
P.S. Whatever the case, I thank all those involved for all the
time/energy/effort they have put into Jabber, be it the original
coders, the transport writers, Rob Norris for his rewrite of
Jabberd2, and those writing here who help to flesh out a pretty
wicked product, etc. People who don't code do not realize just
much how effort goes into these projects. All I did was figure
out how to build JabberD from source, complete with
MU-Conference, JUD, XDB_SQL, etc., on Windows, and MAN talk
about time flying. Only because my wife was visiting her folks
in Brazil for 6 weeks--and I don't have a life :-)--was I able
to get just that minor task done. (I'm sure part of it is
because I suck as a programmer compared to those who do it all
the time :-)).Thanks everyone, seriously.
_______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
