[ejabberd] Authentication and security problems

Adriana Moga adriana.moga at rcs-rds.ro
Wed Apr 13 16:49:10 MSD 2011

On 04/11/2011 05:40 PM, Konstantin Khomoutov wrote:
> On Mon, 11 Apr 2011 16:39:11 +0300
> Adriana Moga<adriana.moga at rcs-rds.ro>  wrote:
> Your post is somewhat chaotic, so I'm not really sure how to detangle
> it into separate problem definitions.
You're right, I will try to be more clear with this.
>> I'm fighting with ejabberd (2.1.5, 2.1.6) on security side.
>> Even I have enabled SSL/TLS and a valid certificate the communication
>> per c2s and s2s is not crypted.
> Enabling STARTTLS does not, by itself, mean c2s communications will be
> encrypted because clients are not required to actually use this feature.
> If you want to *force* usage of STARTTLS, look at "starttls_required"
> option for the ejabberd_c2s listener [1] and the "s2s_use_starttls"
> global/host option which can be set to "required" etc [2].
I enabled "starttls_required" for ejabberd_c2s listener. Could I have 
problems with a self-signed certificate?
> Note that requiring TLS for clients in the case of a corporate server
> is probably a sensible idea, requiring TLS for s2s connections is
> probably insane as this most probably will preclude users from certain
> public servers from accessing your server.  So I think this option
> should be used sparingly; only for the cases if your server is only to
> communicate with other federated servers which your corporation
> controls (and in this case making them communicate via a secure chann
> el (VPN for instance) is probably a way more sensible solution).
> Also keep in mind, that if you really need privacy and integrity for
> certain communications over XMPP, consider using GPG -- this helps
> maintain the required security properties with regard to individual
> conversations even over insecure links.
Do you mean GPG plugin for ejabber clients, right?
>> I can see the passwords in debug loglevel.
>> There is a way not seeing them in plain-text?
> I don't quite get what do you want: you want to make a Joe Random Admin
> not to be able to sniff for the user passwords using the debug log
> level?  If yes, see below.
Sys admin should have full control, so I think it's ok.
>> I'm testing with mnesia local authentication and mysql database
>> storage. With mysql: I tried to modify odbc_queries.erl file to crypt
>> with MD5 algorithm mysql passwords. The user can be registered with
>> MD5 password but nothing more because I don't know what else I need
>> to modify in odbc_queries.erl. Zero knowlegde about erlang. So, even
>> the user is registered he can't log in client because XML parser is
>> interrogating passwords only in plain text. If I paste in client the
>> string with encrypted password from mysql users table is working to
>> log in but is not a nice solution.
>> Here is what I changed in odbc_queries.erl:
>>     add_user(LServer, Username, Pass) ->
>>       ejabberd_odbc:sql_query(
>>         LServer,
>>         ["insert into users(username, password) "
>>       %%  "values ('", Username, "', '", Pass, "');"]).
>> with
>>             "values ('", Username, "', MD5('",  (Pass), "'));"]).
> This looks much the same as the loglevel problem above.
> AFAIK, there's no general solution to this, see [3].
>> Also I have tried to use ldap authentication (Active Directory) and
>> even the ldap port connection is 636 the authentication is working in
>> plain-text. Same stuff, the passwords appear in plain-text.
>> What can I do?
> You have to use the "{ldap_encrypt, tls}" option in your LDAP setup [4]
> -- this activates usage of the LDAPS protocol.
> Note also that if you're using LDAP authentication (seems to be true),
> there's no way to not transfer passwords in clear text--ejabberd will
> use SASL PLAIN mech to carry out authentication.  On the other hand, it
> will not make this mech available to the client unless the STARTTLS has
> been successfully used and an encrypted link has been established.
> In the light of this, I fail to see how the first point of your message
> does apply to the situation: using authentication against LDAP
> effectively forces clients to use TLS.
       There is a method to find if STARTTLS isn't successfully used?
My doubts are when I have enabled "{ldap_tls_verify, hard}" I got "LDAP 
connection failed" and Active Directory authentication didn't work. 
Should be a problem with my self-signed certificate? When I have enabled 
only "{ldap_encrypt, tls}", "{ldap_port, 636}" authentication against 
LDAP is working but I'm not sure if it's working with TLS .

> Also note that there's a way to use Kerberos authentication with
> ejabberd which obviously does not involve transmission of any
> credentials over the wire--look at [5].
I will take a look on this, thanks.
> 1.
> http://www.process-one.net/docs/ejabberd/guide_en.html#listened-module
> 2.
> http://www.process-one.net/docs/ejabberd/guide_en.html#listened-options
> 3. http://www.ejabberd.im/plaintext-passwords-db
> 4. http://www.process-one.net/docs/ejabberd/guide_en.html#ldapconnection
> 5. http://www.ejabberd.im/cyrsasl_gssapi

More information about the ejabberd mailing list