[standards-jig] Re: [Foundation] Last Minute JEP 78 Concerns

Tijl Houtbeckers thoutbeckers at splendo.com
Wed May 28 00:16:35 UTC 2003


Joe Hildebrand <JHildebrand at jabber.com> wrote on 28-5-2003 1:21:28:
>
>Well, sorry it took me so long to get to my mail today.  Here are my
>comments on this thread.
>
>1) I agree with Tijl here that Choice is Good.  We're going to implment
>something in this space in the short term, probably, so we figured it 
>might be good to talk about it in public first.  We've got customers 
>for whom rot13 storage (or equivalents) isn't good enough.

Then I seriously doubt that Dave's proposal is good enough either for 
them. 

But what you suggest here is exactly like what I had proposed, wich is 
worth considering. 

>2) I don't mind this:
>
><iq type='result'>
>   <query xmlns='jabber:iq:auth'>
>      <username>foo</username>
>      <resource/>
>      <edigest id='123'/>
>   </query>
></iq>
>
>Where 123 is a random number chosen when the password set happens, and
>stored alongside the password.  Then:
>
><iq type='set'>
>   <query xmlns='jabber:iq:auth'>
>      <username>foo</username>
>      <resource>bar</resource>
>      <edigest>sha1(streamid + sha1("123" + "pass"))</edigest>
>   </query>
></iq>
>
>Now that password isn't usable for some other system.  Yes, you still 
>have to set your password in cleartext, but we have that problem now.

Not sure what you mean here? You can use the same trick from 
jabber:iq:register, the server sends along a random key. You send back 
sha1("randomkey"+pass) and that's what the server stores. Even though 
if this is sniffed during registration, the cracker can still acces 
your jabber account, he can not use your password for non-edigest 
systems, nor can he use it for any other edigest account expect this 
one. 

You can even remain compatible for cleartext authentication, since the 
server can then sha1("uniquekey"+pass) after it receives it. I guess 
I'd be pretty stupid to run that risk if it can be sniffed, though it 
might be more usefull for clients that support SSL and cleartext but no 
edigest. Still, that doesn't protect you from a smart BOFH that 
monitors for cleartext logins. 


-- 
Tijl Houtbeckers
Software Engineer @ Splendo
The Netherlands




More information about the Standards mailing list