Allow encrypted passwords to be stored in the db

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

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.

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.

I have just read an article (http://www.securitytechnique.com/1/8 ) 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 (http://www.securitydocs.com/library/3439), 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.

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).