powered by Jive Software

XMPP Cleartext authentication detected as security issue

Our Tenable scans have detected “XMPP Cleartext authentication” on my Openfire server (version 4.2.3) which is slated to replace my current Openfire v3.10.2 server soon. When it was detected on my current/old server, I was able to mitigate it by adding/editing the sasl.mechs server property to read: CRAM-MD5,DIGEST-MD5,ANONYMOUS,JIVE-SHAREDSECRET,GSSAPI,EXTERNAL. (removing PLAIN from the list) But when I try the same on my new/upcoming server, Spark fails to connect. But when I remove the sasl.mechs property, Spark connects fine. Unfortunately, I cannot remember if changing the sasl.mechs was the only thing I’d done or if I am missing additional steps. Any insights? Has anyone else had to deal with mitigating this issue?


You may try with 4.3.0 version as it is the latest release currently. Also, what version of Spark? @speedy used to play with sasl.mechs properties, maybe he will have something to add.

the setting on this has changed a bit in the more current release. the properties has changed, but the sasl mechs can be changed via the gui. I have nessus at work, so I can try and confirm some of this on Tuesday if needed.

Thanks for getting back to me. Yes, I was using Spark 2.8.3 to connect. Upgrade to Openfire 4.3.0 ? I hadn’t realized that it came out of beta yet.

That would be of great help. Thanks!

Any further news on this? A resolution?

I have tried to create a system property sasl.mechs with CRAM-MD5,DIGEST-MD5,ANONYMOUS,JIVE-SHAREDSECRET,GSSAPI,EXTERNAL value on Openfire 4.3.2. Restarted Openfire. Was able to login with Spark 2.7.7, 2.8.3, 2.9.0 nightly build. Not sure if this setting does anything. Speedy mentioned something has changed in recent versions. Maybe there is a different property or one has to use different syntax. Don’t have Nessus or Tenable to tell if it changes anything for scanning.

Thanks for testing. Can you send a screenshot of the sasl.mechs you applied at your console? Here is a screenshot for mine:

Does your console also show the sasl.mechs enumerated like this, too?


1 Like

No, i have a single entry with all the values separated by commas.

I was thinking that in older openfire, openfire would allow non-sasl authentication (iq:auth). In older spark versions (pre smack 4), spark would failback to using iq:auth. if the other sasl were not working or unavailable.

using plain is not ideal, but the creds are encrypted in transport, as long as you have your server to “require” encrypted connections

Weird. So, like with what wroot did, I added the sasl.mechs (without PLAIN). And I immediately got an connection error from Spark (v2.8.3); I also have the inverse plugin installed and when I try to login from a browser, the login spins. But when I re-add “PLAIN” to the sasl.mechs setting, my spark client immediately works and the web client also worked (after a refresh and re-login). My openfire version is 4.3.2 - reaching this version level through updates from 4.1x, I think. Is there something I should check? Maybe in the database? Also, it authenticates to our active directory (while using Postgres as the backend database).

Thanks again for your assistance.

I don’t have AD, so i could only test with local database. Maybe with AD it needs something else.

if you are using AD, then you are limited to the sasl mechs supported by AD.

1 Like