[JDEV] XDB_SQL: Problems with the stored "token" value in "users0k" table

[Alexis Darnois]

Hi,

Thanks for your answer but my question was more on a XDB_SQL issue than a Jabber issue. Have you any idea about this problem ?

Alexis Darnois

----- Original Message ----- 
From: "Tijl Houtbeckers" <thoutbeckers at splendo.com>
To: <jdev at jabber.org>
Sent: Thursday, April 17, 2003 7:26 PM
Subject: Re:[JDEV] XDB_SQL: Problems with the stored "token" value in "users0k" table


> "Alexis Darnois" <alexis.darnois at terravirtual.net> wrote on 15-4-2003 
> 19:07:40: 
> >
> >Hi all,
> >
> >About the "token" field written by XDB_SQL module  in the "users0k" 
> >table, it seems that the original token is transformed before beeing 
> >inserted, the token is generated by this line in "mod_auth_0k.c" (line 
> >94):
> 
> Note that there are important issues with 0k.
> 
> Here is a repost (from someone else) from the SJIG mailinglist:
> 
> ----------
> 
> Matthias Wimmer <m at tthias.net> wrote on 12-4-2003 20:00:36:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>  
> Hi!
>  
>  
> I see two problems with the 0k authentication protocol of Jabber and
> would like to get some comments on these two issues.
>  
> 1.
> With each login a counter is decremented by the server. This counter is
> sent to the client before it authenticates with the server. (To tell the
> client which hash it has to send to the server.)
> This counter can be queried by everybody as it is send to the client
> before it is authenticated. With this information everybody can
> determine how often a user (that uses 0k) has logged in to its account.
> By checking the counter regularly one can check at which times a user
> (that uses 0k) logs in to the Jabber server.
>  
> 2.
> If an attacker manages to redirect a login attempt to its own server
> (e.g. by a DNS attack) he can query a hash value with a low sequence
> number from the client. With this hash value he can calculate all the
> following hash values and use them to login to the (real) Jabber server.
> Especially he can use this hashes not only at the moment he gets them.
> As he knows all hash values with a higher sequence number he can use
> them later - after he has removed everything that could be used to
> identify the attacker.
>  
> I think these two problems make 0k-authentication less secure than
> digenst authentication. I propose that Jabber server administrators
> should disable 0k as most clients will use digest authentication then.
>  
> One small note: Jabber's 0k authentication protocol is not a "zero
> knowledge authentication" protocol as this term is defined in 
> cryptology. 
>  
>  
> Tot kijk
> ~    Matthias
>  
> - --
> Fon: +49-(0)70 0770 07770       http://matthias.wimmer.name/
> Fax: +49-(0)89-312 88 654         jabber://mawis@charente.de
> HAM: DB1MW     OpenPGP: http://matthias.wimmer.name/encrypt/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.1 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>  
> iD8DBQE+mFRDJ/5jVqqDmvkRArB2AJ4/xChJ61w1n+qrbHxhxejU1sjWcACfdsSS
> 7+FM81PhysGqcJA/AevAFMM=
> =kazY
> -----END PGP SIGNATURE-----
>  
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig
> 
> -- 
> Tijl Houtbeckers
> Software Engineer @ Splendo
> The Netherlands
> 
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev