[standards-jig] Refreshing the Thread: EDigest
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:
>-----BEGIN PGP SIGNED MESSAGE-----
>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.
Software Engineer @ Splendo
More information about the Standards