[standards-jig] Refreshing the Thread: EDigest

Tijl Houtbeckers thoutbeckers at splendo.com
Wed May 28 13:25:32 UTC 2003

Dave Smith <dizzyd at jabber.org> wrote on 28-5-2003 15:14:36:
>Hash: SHA1
>On Wednesday, May 28, 2003, at 06:47 America/Denver, Tijl Houtbeckers 
>> I'm not sure how it'd be possible for digest to work if you don't 
>> store the password in plaintext? (since digest has to sha1(streamid 
>> + pass)). 
>Oh, I see. What I meant was that digest/plaintext could still be a 
>valid option, it'd just have to use a plaintext version of the 
>password (so you'd have to provide a plaintext and edigest version of 
>your password during registration). Remember edigest is mutually 
>exclusive to digest/plaintext for this very reason.

And what I meant is that it's possible to write an authentication 
module that uses plaintext (so it's compatible with old clients) that 
does not store passwords in plaintext, but uses the edigist store 
instead. From a security point of view they are mutually exclusive in 
most cases, but technically they are not. For digest this is ofcourse 
not possible, since you must have stored the password in plaintext 

>> I mean, currently we've been talking about how jabber:iq:auth should
>> work with edigest. We could also make it possible to use edigest for
>> jabber:iq:register, that way your password would never be exposed to
>> the server, not even during registration. The disadvantage is that 
>> the server can't make any checks to see if the password is any good 
>> (in other words refuse password like "root", "god and "sex" or that 
>> equal the username) but I'm sure some paranoid people would like it.
>Well, technically you could write a module that takes a dictionary and 
>uses the "random id" to generate hashes of those passwords to ensure 
>that people don't use easy to guess words.

Would take up quite a lot of CPU though, and you can't check things 
like lenght of a password. I mention this we'll have to make a choice 
(or allow 2 possibilities) between sending the actually password during 
registration (so the server can check if it's not stupid and long 
enough) or sending sha1(pass+randomkey) so that the server won't *ever* 
know your password. We already have the first option, wich could be 
adapted for edigest (and cleartext as I note above) with purely changes 
on the server, but that would lock out normal digest. So maybe you'd 
have to specifically request edigest there. For the second method  
something new would have to be made (probably like with edigist/iq:auth 
sending along the id in the tag when you request different methods). 

>I think there is still some clarification needed around how edigest 
>fits into iq:register -- I'll work with stpeter to clarify this in the 
>JEP so that everyone can see all the pieces put together.

I'll wait for that then.

Tijl Houtbeckers
Software Engineer @ Splendo
The Netherlands

More information about the Standards mailing list