[ejabberd] Ejabberd with Drupal
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
>> * 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
>> successful against the ejabberd server). Add an extra insert on
>> successful drupal registration to add a user to the ejabbred:users
> 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
> 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.
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