[Standards-JIG] Re: JEP-0077: In-Band Registration

[Tijl Houtbeckers]

On Mon, 17 Jul 2006 20:56:37 +0200, Piotr Szturmaj <gacek999 at tlen.pl>  
wrote:

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

SASL RFCs:
http://asg.web.cmu.edu/sasl/sasl-ietf-docs.html

DIGEST-MD5 with SASL:
http://www.faqs.org/rfcs/rfc2831.html

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.