[ejabberd] Re: Ability to use any ldap account with no password

Oleg Kivel olegk at dp.ru
Fri Dec 3 12:44:51 MSK 2004


>> Could you explain it a little bit more?
>> 
>> Why can the ejabberd use the verified password in one case and can not
>> do the same in another case?
>> 
>> 

LJ> It's two different kinds of passwords. A shared secret mechanism (as in
LJ> the legacy jabber password system implemented in ejabberd) implies that
LJ> passwords are stored in the clear on the server. Traditional unix-style
LJ> passwords are not stored in the clear on the server - in that case the
LJ> server only relies on the ability to verify that a given password
LJ> matches the one stored in the server. What the client calls clear-text
LJ> passwords are the second kind since the passwords in fact are _trans-
LJ> mitted_ in the clear from the client to the server. This is the reason
LJ> you want tls in this case. The legacy jabber password system transmits
LJ> hashes of passwords over the wire which is not clear-text.

LJ>         MVH leifj

As I understand, when I use {auth_method, ldap}:

1 - The ejabberd just transmit username (uid) and password, supplied
by the client to ldap-service and wait an answer about positive or
negative binding with these credentials. If ldap can't perform binding
with these credentials (wrong password), then the ejabberd deny the
client connection. And it works if I check the "Use plain text
password" box.

2 - If don't I check the "Use plain text password" box, then the
ejabberd do the same things: just transmit username (uid) and password
to the ldap and wait an answer about binding. And if I supply wrong
password, then the binding will be unsuccessful, and the ejabberd will
get the negative answer from ldap, BUT IT DONT'T DENY the client
connection (as at first case).

Am I not right in the ejabberd's auth schema understanding?


And the situation is the same if I use SSL (if you talk about it)

Kivel Oleg.



More information about the ejabberd mailing list