[ejabberd] Ejabberd with Drupal

Simon Tennant simon at imaginator.com
Sat May 3 13:06:50 MSD 2008


Brian Cully wrote:
> On 2-May-2008, at 12:11, Simon Tennant wrote:
>> * ejabberd stores passwords in clear
> 
> 	You think this is a lose, but it's not. Storing passwords encrypted  
> almost always means the common channel is vulnerable. Storing  
> passwords in the clear allows you to secure the common channel at the  
> cost of vulnerability from the db. Securing the db is still much  
> easier than the common channel, which is basically impossible. Also,  
> if someone got into your db, I bet you're already plenty hosed, and  
> XMPP is probably the least of your problems.

Lest we not get sidetracked by a flame war that's been hammered our many 
times here before on jabber related mailing lists:

I don't see an either/or situation. Securing a common channel has been 
solved countless times in other communication systems using SSL / TLS 
type methods. Secure the channel then pass the data through it.  This 
works for IMAPS.  Works for http based auth running inside https. 
Neither of these require passwords sitting in clear on a disk, backup 
spool, backup tapes etc.  I understand some of the reasons for using 
SASL in XMPP's case, like wanting to just secure the password and pass 
everything else in the clear, however, *in my opinion*, if the server is 
already only accepting encrypted connections, there's no reason to take 
the risk of exposing users' passwords to 
$HACKER/$SYSADMIN_ACCIDENT/$DISGRUNTLED_DEVELOPER.

>> * register on XMPP-client - creates user in ejabberd:users
>> * register on drupal - creates user on drupal:users
>> Proposal: change drupal to use the xmpp.module (if I understand
>> correctly this then creates a user in drupal:users if authentication  
>> is
>> successful against the ejabberd server).  Add an extra insert on
>> successful drupal registration to add a user to the ejabbred:users  
>> table
> 
> 	Unless you think about this very carefully, I can guarantee that this  
> set up will lead to conflicts. What happens when someone registers via  
> XMPP with a name, and someone else does the same name on Drupal before  
> they can communicate their state to each other? If you said "patch  
> conflict", you win!

I guess I win, but given the situation, I am not seeing anything cleaner 
than multiple hacks.

One proposed solution was to push everything back into an LDAP database 
(something I'm reasonably comfortable with after designing a centralised 
authentication system for a 300 strong server environment).

I've resisted this approach for two reasons:  Firstly, we have lots of 
other infrastructure build around the user's table already.  Secondly, 
it complicates the building of applications that depend on many username 
related queries.

> 	What do you think of an authentication system that isn't necessarily  
> consistent between nodes? Maybe you have different needs, but I  
> wouldn't use it.
> 	It seems complicated because you're thinking about it wrong. Try a  
> new tack.

I am all ears.

S.
-- 
Simon Tennant _____________________________________________

fixed: .uk +44 20 7043 6756          .de +49 89 420 955 854
   mob: .uk +44 78 5335 6047          .de +49 17 8545 0880


More information about the ejabberd mailing list