Proposed in PR: JDBCAuthProvider: adding support for bcrypt and more by trumpetx · Pull Request #390 · igniterealtime/Openfire · GitHub
The following (related) features have been added to the JDBCAuthProvider:
1) BCrypt support for passwords
Just like MD5/SHA###, JDBCAuthProvider can now lookup and compare bcrypted password hashes (or more accurately, the plain text password to a bcrypt hash). Furthermore, password resets will support bcrypt as well (if configured).
2) "Chained" password hashing (still defaults to simply "plain")
As happens sometimes with "legacy" systems, password hashes are deemed "bad" over time. Imagine when you started your current job and saw plain MD5 hashes sitting in the "password" field of your users table. Your first though was probably "We should use SHA256 (or whatever)", but instead of simply resetting everyone's password you simply perform a SHA256 hash on top of the MD5 hash and modify your code accordingly. Then, you decide to integrate Openfire to your database. Ack! your passwords aren't simply SHA256'd, they're MD5'd then SHA256'd!
Enter chained password hashing. Simply configure the "jdbcAuthProvider.passwordType" param to be a comma separated list of valid values. With a new configuration of "md5,sha256", instead of simply comparing the submitted password to MD5("password"), JDBCAuthProvider will compare the database stored hash to SHA256(MD5("password")).
One caveat: when using bcrypt - it needs to be the "last" in the chain. BCrypt is pretty cool as it creates a different hash every time. Instead of comparing HASH_ALG("password") == PASSWORDHASH, you call a BCrypt method to mathamagically figure out if the plaintext password could create the given hash that is provided.
3) Submission of hashes in lieu of passwords (defaults to false)
Here's the situation: You're integrating Openfire into your application and logging users in via your application using something like Smack. You're a responsible developer so you have NO IDEA what the user's password is. You forgot it as soon as you could and only ever stored it in a char[] (good for you!) Now you need to log your user into Smack. Sure, you can go write your own custom JDBCAuthProvider, but wouldn't it be neat if you could simply configure the perfectly good one to do what you need? Well, now you can *tada*.
As mentioned in the Javadoc, this feature is the logical equivalent of:
* jdbcAuthProvider.passwordSQL = SELECT MD5(password) FROM user_account WHERE username=?
* jdbcAuthProvider.passwordType = plain
-OR-
* jdbcAuthProvider.passwordSQL = SELECT password FROM user_account WHERE username=?
* jdbcAuthProvider.passwordType = md5
Why not simply configure for the former situation? Well, then the user would need to know the password hash to log in via the web console or the user wants to log in to chat directly with Adium. (And wouldn't you know it, the web console input truncates password length shorter than a bcrypt!)