It's great that you're concerned with strong hashing for your passwords. I would recommend the use of the scrypt libary. Colin Percival, who invented it for use with tarsnap, has written a great comparison of scrypt, available on the tarsnap website (sorry, can't post more than two links due to rep < 10) to other well-known and strong PBKDFs like bcrypt and PBKDF2 that answers the question of why scrypt may be advantageous in use over other PBKDFs from a technical perspective.
I am generally cautious about jumping on the bandwagon for the use of crypto that hasn't been around a while and been well-vetted by the crypto community. Thus, I had a bit of reservation about using scrypt, since it is still rather "new" in that regard. I consulted security expert Steve Gibson regarding the question via Twitter, and this was his reply:
@SGgrc Any thoughts on use of bcrypt vs scrypt for PBKD for a web aplication? [sic]
@geekmuse SCrypt more strongly resists hardware acceleration than
BCrypt. So I'd say, if your applicaton CAN use it, do use it. :)
@SGgrc Will do -- and thanks for the info! My only hesitation was
seemingly less thoroughly vetted by the crypto community.
@geekmuse Understood, and in crypto, being conservative is never
wrong. But currently, SCrypt is the best memory-hard solution
available.
Additionally, ColdFusion's built-in crypto (Enterprise edition, at least) uses RSA BeSafe's library, which is now strongly suspected of being compromised due to the NSA (depending on which PRNG one uses, but still...), so you're doing the right thing by looking at some of the more recently published algorithms.
There is a Java-based scrypt implementation available on Github (github.com/wg/scrypt), which should be quite amenable to use in your ColdFusion application.
Lastly, while I know your question specifically mentions strong crypto for user passwords, depending on the sensitivity of the data you're storing, you might also want to seriously consider encrypting the sensitive data while it's at rest in the database as well. That way, if your data is ever compromised, you can rest a bit easier knowing it was encrypted at rest (unless your key is compromised as well, but you would want to store that in a different location than your actual database that your application has access to).