[Standards-JIG] Re: JEP-0077: In-Band Registration
thoutbeckers at splendo.com
Mon Jul 17 20:10:00 UTC 2006
On Mon, 17 Jul 2006 20:56:37 +0200, Piotr Szturmaj <gacek999 at tlen.pl>
> Comparing to existing approach we increase the security much.
No you don't. You increase security the maybe-sort-of-kinda-"I'm feeling
lucky" way. It's already been discussed in the "edigest" thread.
If you're making some custom solution, you can go ahead and implement
something (salt with XMPP or Szturmaj). Or think of some other obscure
mechanism. But discussing this on SJIG defeats it's purpose, cause it's
only an improvement if others don't start using it.
Again, I emphasize one last time, if you use the hashed password instead
of the plain text password during authentication (since you want to store
the hash on the client, not the plain text password, this is what you plan
to do), it doesn't matter that the plain text password is no longer stored
anywhere (server, client, the moon, etc.), because you DO NOT NEED IT to
log into your account. You just need the hash.
A solution for this problem could, is salting based on realms, so multiple
services in the same realm can be used (such as Jabber), but you can still
use the same password on different realms without your password being
compromised. To make maximum use of this you should use a standardized
technology. Luckily SASL support this, and Jabber supports SASL. Note that
this will only work if you always use the same nonce in MD5-DIGEST, and
that enables replay attacks! unfortantly, it's one or the other..
This does not cover in-band registration, but in-band registration is
discouraged anyway. If you want to standerdize in-band registration, I'd
suggest talking a look at SASL and it's DIGEST-MD5 mechanism and see how
you could do in-band registration for this.
DIGEST-MD5 with SASL:
If this is all too complex or not useable for what you have in mind, you
could always consider doing your own implementation, and possibly
standerdizing it here. But don't expect too much considering the result of
a loooong discussion about 3 years ago was that the most logical thing
would be to standardize around SASL instead of coming up with our own
little plans. Use of SASL has only increased since then, of course.
More information about the Standards