powered by Jive Software

Properties not encrypted in Openfire 4.2.2

When doing a clean install of Openfire 4.2.2 in our test environment, I’ve noticed that the database properties are no longer encrypted, despite having chosen Blowfish and an encryption password during setup.
It was working just fine in 4.1.3 and 4.1.6. The Openfire server is working as expected after installation and configuration, so it’s just the properties that aren’t encrypted which bothers me.

Am I missing something or doing something wrong during setup? Or is it a bug in 4.2.x?

Details:

  • Found on Windows Server 2016 with SQL Server 2016 SP1
  • Found on Windows Server 2012 R2 with SQL Server 2012 SP3
  • Using LDAP integration to Active Directory domain
  • Used Openfire 4.2.2 with bundled JRE. Tried both 32-bit and 64-bit versions, same error. And the same in 4.2.1 (64-bit, bundled JRE) as well.
  • Default installation performed as a domain administrator

Edit: The database username/password properties in openfire.xml are encrypted, it is just the ones in the ofProperty table that are in plaintext.

That definitely sounds like a bug. Do you know if you manually encrypt the property via the admin UI, does it work (without corrupting the XML version) ?

If I manually create a new property in the admin UI and select “encrypted” it gets encrypted in the database. And if I click on the “Encrypt” icon for database.defaultProvider.password that property also gets encrypted in the database. So the encryption function must be working. Also noted that on a fresh install the admin UI says that the database and LDAP password properties are encrypted/hidden, but in reality they are unencrypted in the database.

I’ve been poking around in the recent changes since 4.1.6, and found https://issues.igniterealtime.org/browse/OF-1159. I guess it must be the setup process which doesn’t send the new encryption parameter to the setProperty function when running the setup, but I’m not sure.

I worry that hitting the “encrypt” button double-encrypt the password in the XML, preventing you from starting up next time, though.

But yes, almost certainly a side-effect of OF-1159.

I just tried restarting the Openfire service after hitting the encrypt button for the database password. The service starts just fine and I can logon to the admin interface. I haven’t verified if it is actually double-encrypting the password in the XML file, but at least Openfire is still working :slight_smile:

Yeah, definitely a bug, raised at https://issues.igniterealtime.org/browse/OF-1506

Luckily there is an easy work around :slight_smile:

Thank you for raising the defect, much appreciated. Can you add an extra note to the issue? It’s not only the database username/password, also the LDAP username/password that’s left unencrypted.
I have compared the ofProperty tables between 4.1.6 and 4.2.2 and it seems to be the following properties which are affected in a default LDAP integrated setup:

database.defaultProvider.password
database.defaultProvider.username
ldap.adminDN
ldap.adminPassword

Have done, thanks for the feedback! Again, I suspect using the “+” to encrypt them may well be a workaround.

I have been experimenting this with Openfire 4.6.0 (Centos 7) where a comment in security.xml says:

<!-- 
  Any other property defined in this file will be treated as an encrypted
  property. The value (in clear text) will be encrypted and migrated into 
  the Openfire database during the next startup. The property name will 
  be added to the list of encrypted properties and the clear text value 
  will be removed from this file.
  
  <foo><bar>Secr3t$tr1ng!</bar></foo>
-->

However, ldap.adminPassword or any other additional property I list in security.xml in the commented section gets only migrated to the database but unencrypted. Do I understand to comment correctly?

Also tried to set ldap.adminPassword in openfire.xml and then refer to it with the name tag in the encrypt section in security.xml with no success.