Bug: Encrypted Passwords in Openfire's Database don't offer more security than Plaintext Passwords

Openfire Openfire Dev
1

Hi,

Disclaimer:

I did not send this privately, as this information is already found in some shaddier part of the web (I stumbled upon it while searching for “openfire blowfish”).

Background:

While puppetizing the deployment of Openfire, i found the need to parametrize the addition of Openfire users without using the webUI. The only mean to do so i found was to modify directly Openfire’s Database.

Issue:

The encrypted passwords in Openfire’s database don’t offer more security than stored plaintext passwords.

http://issues.igniterealtime.org/browse/JM-291 This issue, while dated, still represent the encryption implemetation of Openfire’s password storage.

And i have to disagree with the following quote from JM-291:

“I changed this issue report to store encrypted passwords instead of hashed passwords. Encryption seems to offer the best mix of security and convenience.”

Hashed passwords offer better security because an attacker getting a dump from openfire’s database (some CVEs speak of XSS issues for Openfire, a poorly secured sql server, …), hashed passwords would not be able to be deduced without bruteforcing, while blowfish encryption is symetric, and the encryption key is available in the same database, with that information it is easy to decrypt instantly all the encrypted passwords in the database (see attached script).

To my knowledge, use of sha1 digests instead of passwords is encouraged in XEPs (SCRAM-SHA1), their should be no need for the server to keep the whole password of each users.

As adding a user directly in database has been asked several time in Openfire support forum, and to show that blowfish is a two way street, here is a sample use of the attached script:

Decryption

First get the user encrypted password:

~# grep OFUSER /var/lib/openfire/embedded-db/openfire.script | grep admin
INSERT INTO OFUSER VALUES(‘admin’,NULL,‘b7d7abef353938c500b4a2d2c1a1c33387e5e5c52aa57b0b85c22a2f6b 45c3e5’,‘Administrator’,‘admin@somewher.org’,‘001369931816267’,‘0’)

Then the encryption key:

~# grep passwordKey /var/lib/openfire/embedded-db/openfire.script
INSERT INTO OFPROPERTY VALUES(‘passwordKey’,‘ABCDEFGHIJKLMNO’)

We can now get the admin password using the following command:

~$ ./openfire_cipher.py dec -c b7d7abef353938c500b4a2d2c1a1c33387e5e5c52aa57b0b85c22a2f6b45c3e5 -k ABCDEFGHIJKLMNO
notsafepwd

Encryption

Either way we could generate an encrypted password for the ‘notsafepwd’:

~$ ./openfire_cipher.py enc -p notsafepwd -k ABCDEFGHIJKLMNO
d34bc2e538eb9166f09f0f156cd65873aa08aae1f588fe1447e1ad6703722369

… and include it in the database

If we want exactly the same encrypted password, just provide the original cbciv (first characters of the encrypted password):

~$ ./openfire_cipher.py enc -p notsafepwd -k ABCDEFGHIJKLMNO -i d34bc2e538eb9166
d34bc2e538eb9166f09f0f156cd65873aa08aae1f588fe1447e1ad6703722369

Kind regards,

1 Like
2

Thanks for sending along this example python script, it will be very useful for those hoping to decrypt the database passwords outside of java

Development resources with openfire are limited, so patches are certainly welcome if you think of a way to correct this.

daryl

3

Yes, seeing how often the question was asked in this forum, i do believe it could be of use, there are a few use cases i can think of when you don’t want to go through a webUI, and i did not find any other way to go (and count me in the camp of “better have no security than an unfounded feel of security”) … but for decryption only i could have gone with the several similar implementation i found around the web (wierdly, mostly in php … probably because of the availability of mcrypt in php).

Fixing this would not be code intensive, the main time sink being determining an implementation choice, because keeping backward compatibilty or having an automatic update would require either a new field “sha-1 password” in OFUSER (and modifying a database structure is never a happy process), either use the “encrypted password” field, but for that you would need an update script to convert the encrypted passwords into hashed passwords, and there would be no version rollback possible in that case. So no silver bullet here.

For the second option, the code (appart from the database conversion) might be already done (i did not check it but this seems sensible):

http://stackoverflow.com/questions/3409657/openfire-sha-1-passwords-without-blow fish-encryption

Cheers,