Allow encrypted passwords to be stored in the db


Add option to store encrypted passwords in the database. The symmetric cipher would be stored in the wildfire confige XML.

Two options for enabling this:

  • Re-use existing password column for encrypted content.

  • Add a new column for encrypted passwords.

The second method would make it easier to switch from non-encrypted to encrypted and would allow us to reliably determine which mode is currently active.




March 21, 2006, 3:26 AM

You say encryption will be enabled by default? But this option will affect only new users? Dont forget to mention about this new feature in 2.6.0 announcement

March 20, 2006, 8:12 AM

I'm happy to finally be able to post an update on this issue. I've completed work on this issue and am about to check it all in.

A new column was added to the jiveUser table called encryptedPassword. The password field was also updated to allow for null values. A new Wildfire property called "user.usePlainPassword" controls whether plain text or encypted passwords will be used.

  • When true: plain text password will be used from the "password" column. This mimics the behavior in older Wildfire releases. Note that you must explicitly set this property with a value of true if you want to use plain text passwords. The default is now to use stronger security.

  • When false: passwords will be encrypted in the "encryptedPassword" column using the Blowfish algorithm. The encryption/decryption key is stored as the Wildfire property "passwordKey" and is automatically generated if not present.

Because of the way the feature is implemented, it's a seamless upgrade process – both plain text and encrypted passwords can exist in the same database. Any time a new account is created or a password is updated, the password will stored as plain text or encrypted depending on the value of "user.usePlainPassword". It should be fairly easy to create a script to change all passwords in an existing database to either plain text or encrypted if people desire this feature.

January 23, 2006, 3:45 AM

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

Michael Michael
December 14, 2005, 5:53 AM

I have just read an article ( ) which describes some methods how a (salted) hash should be employed:

"The password generation process using salted hashes looks like this:

1. Prompt the user for a password.
2. Generate a random salt (i.e.- a random string of bits.)
3. Prepend the salt to the password.
4. Hash the salted password.
5. Store the salt and the salted password in the password database.

The process of checking the password is now:

1. Retrieve the user's salt from the password database.
2. Prompt the user for a password.
3. Append the password to the salt.
4. Hash the salted password.
5. Compare the result from step 4 with the salted password in the password database."

Also found some Java code (, but am not sure whether this is compliant with XMPP-Jabber authentication methods. SHA-1 returns a Base64 encoded final string representation. It generates a 160 bit hash string.

Guus der Kinderen
October 12, 2005, 3:43 AM

You're saying that adding the option to store hashed passwords in the database excludes all but plain-text authentication. Is that because that implies the client should send hashed passwords as well? If so, a compromise could be a password received by the client checked (and stored) in a hashed form on the server, with a function defined server-sided. That at least would secure the storage of the password (the database).

Your pinned fields
Click on the next to a field label to start pinning.