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

[Robert Norris]

> 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)

Obfuscation adds nothing, IMO.

> 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. :-)

The only thing transport authors can really do is not store passwords,
which means getting a registration from the client for each time that
they want to use the transport.

We could possibly develop protocol to allow the client to pass auth
information when it sends presence to the transport, though that kinda
sucks, because it requires the client to know something about the
transport (including the fact that it is a transport).

Alternatively, we could have the transport ask the client for auth
information when it needs it. Again, more protocol required.

And although this has nothing to do with jabberd2, you all still have to
be nice to me ;)

[snip]

> 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.

Each to his own on this. I agree to disagree.

> 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.,

OK, I've looked into, and it seems fairly straightforward to add a
config option to j2 to tell it to store SHA1-hashed passwords, with the
caveat that the "digest" method will no longer be offered.

On its own, this scares me, so we'd also need an option to require
SSL/TLS before auth can happen. This is slightly more difficult (due to
limitations in the current codebase), but really necessary for this.

Also, it appears I may have been mistaken with regard to DIGEST-MD5.
I've just reviewed the spec (RFC2831), and it has this as part of its
calculations.

  A1 = { H( { username-value, ":", realm-value, ":", passwd } ),
       ":", nonce-value, ":", cnonce-value, ":", authzid-value }

The username, realm and password values will be static, in most cases,
which means that it should be possible to store this hash rather than
the password, and then used this value rather than recomputing it from
the passowrd each time. I think this will place a restriction (a single
user cannot appear in multiple realms), but that doesn't seem to be too
much of a problem.

So, sure, this stuff can be implemented, and I'm actually starting to
thing it might be a good idea (if only to shut you lot up ;).
Unfortunately, j2 is currently in feature freeze, and I have very little
time to work on it at the moment. But we'll see.

> 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 :-)).

You're welcome. At least for me, good feedback and warm fuzzies work a
treat :)

Rob.

-- 
Robert Norris                                       GPG: 1024D/FC18E6C2
Email+Jabber: rob at cataclysm.cx                Web: http://cataclysm.cx/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://www.jabber.org/jdev/attachments/20030917/2037afa2/attachment-0002.pgp>