> I'm guessing posting anything about our password hashing will be frowned upon due to the context of this question.

The only way it could be harmful to disclose the hashing method is if you're using an insufficient one.

+1 for bcrypt - "ordinary" hashing algorithms were made to compute as fast as they can, which is exactly the opposite of what you will want for your system. Rainbow tables are so quick and easy to make - IIRC it currently takes only some hours to compute all MD5 hashes for passwords up to 8 characters long on a system with some good graphic cards. What you want is an algorithm which takes an up-to-date system some 10-100ms to compute a hash - bcrypt is configurable in its complexity (time to compute hash), and you should adapt the parameters every 1-2 years to increase the complexity.

Security through obscurity should not used. Just saying. IMO, revealing the method used should not become an issue just like the reason why the more trusted crypto algorithms are publicly posted.

That said, bcrypt and a time/attempt limited lockout should go a good ways in securing your site.

Salt. Seriously. A big, long, gnarly-looking salt. Preferably a unique salt per user. Really, even just that is sufficient, even if stored right next to the hash. It means doing a bruteforce/dictionary attack one user at a time rather than one bruteforce/dictionary attack of all the users at once (static salt) or just googling the hash (unsalted hash).

Also, are these passwords encrypted or hashed? Those two are miles away from each other and you guys are using both words nearly interchangeably. If encrypted, where is the key? Was it compromised?

MD* - No, SHA* - No, Bcrypt - Yes!, Scrypt - Not yet (PDI). Make sure you also calibrate the work factor for Bcrypt, too. Then, write a blog entry about your findings.

bcrypt http://en.wikipedia.org/wiki/Bcrypt